You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Tim Funk <fu...@joedog.org> on 2003/05/18 18:49:07 UTC
Re: cvs commit: jakarta-tomcat-5 TODO.txt [Q about making methods
final]
The following article states that making things final does not improve
performance. I am just throwing this out since one of the todos below was
"making methods final to improve runtime performance".
http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw01JavaUrbanLegends
I tried looking for similar discussions in the archives with no luck. If this
was already discussed, can anyone post the link?
I an not interested flame war and I am not vested in either way (final vs
not-final), just curious if anyone has counter-evidence to the above. (with
1.3, 1.4 jvms)
-Tim
remm@apache.org wrote:
> remm 2003/05/14 10:39:04
>
> Modified: . TODO.txt
> Log:
> - Update todo list.
>
> Revision Changes Path
> 1.2 +8 -5 jakarta-tomcat-5/TODO.txt
>
> Index: TODO.txt
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-5/TODO.txt,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- TODO.txt 24 Apr 2003 19:36:50 -0000 1.1
> +++ TODO.txt 14 May 2003 17:39:04 -0000 1.2
> @@ -1,16 +1,19 @@
>
>
>
> -* Filter mapping optimization
> -* Request dispatcher optimization
> +* Filter mapping optimization (remm)
> +* Request dispatcher optimization (remm)
> * Tag plugins for JSTL
> * Optimization of BASIC authentication handling (remm)
> * (optional) Optimization of DIGEST authentication handling
> -* Realm / auth refactoring (one of the goals would be to add better
> +* (optional) Realm / auth refactoring (one of the goals would be to add better
> support for DIGEST)
> * (optional) GUI for the deployer
> -* Stack size reduction (removal of valves, making methods final to improve
> - runtime performance)
> +* (optional) Stack size reduction (removal of valves, making methods final
> + to improve runtime performance)
> +* Deployer refactoring (remm)
> +* Documentation updates for new user guide book (remm)
> +* Split main catalina.jar (remm)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-5 TODO.txt [Q about making methods
final]
Posted by Remy Maucherat <re...@apache.org>.
Tim Funk wrote:
> The following article states that making things final does not improve
> performance. I am just throwing this out since one of the todos below
> was "making methods final to improve runtime performance".
>
> http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw01JavaUrbanLegends
>
>
> I tried looking for similar discussions in the archives with no luck. If
> this was already discussed, can anyone post the link?
>
> I an not interested flame war and I am not vested in either way (final
> vs not-final), just curious if anyone has counter-evidence to the above.
> (with 1.3, 1.4 jvms)
Well, I don't really care about that item. Costin proposed it some time
ago (it was stack size reduction), and that seems like a good idea. This
was meant primarily to ease debugging (long traces are harder to read),
and to get a possible boost in the max throughtput (theorical benefit at
best).
BTW, I think the article is BS ;-)
I mean, look at points 1 and esp 3. IF you code TC using Strings
(immutable object are fine, right ?) and sync (Hashtables anyone ?)
everywhere, it's not going to work (or rather, it will, but it will be
slooooooooooow) ;-) So that leaves item 2, which might be correct. The
author is correct, I have no data to justify one or the other. However,
judging by the rest of the argument, I'd say final could very well help
performance (but IMO if you're trying to optimize the amount of method
ivocation - except in some very specific cases -, you have no
performance problem worth solving :) ).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org