tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Object pooling performance
Date Tue, 08 Jul 2003 20:17:35 GMT
Marc Saegesser wrote:
> Another thing to consider when evaluating object pooling is the expected
> lifetime of the objects.  On modern JVMs with generational memory stores,
> objects with a short lifespan (say the duration of a single HTTP request)
> will probably never leave the nursery.  Pooling these kinds of objects
> usually degrades performance rather than improving it.
> I've just finished some performance research on Tomcat 3.2 (I know, I
> know...) and one of the things I found was that the o.a.u.MimeHeaders and
> related classes were a huge performance bottleneck.  The existing code went
> to great lengths to avoid creating 'garbage' and the result was code that
> was very slow.  I replaced it with a much simpler set of classes that
> basically ignored the GC impact and saw a 15% performance improvement under
> load.

I find that *really* odd. We're not talking about an object pool here 
with the MessageBytes and the others, but rather a thread local direct 
reference. The code in utils seems very efficient to me, and even the 
worst JIT should look good tuning the array based algorithm of the 
HTTP/1.1 for your CPU.
Using and manipulating Strings and stuff instead of that is dead slow in 

I confirmed with tests, as well as OptimizeIt (I don't know how real and 
accurate the OptimizeIt numbers are).

I can't be so affirmative when it comes to real object pooling, such as 
tag pools. However, I believe that GC is a problem for scalability no 
matter how good the VM is on a large scale system. These kinds of pools 
can be very easily disabled or configured, so I don't see any problem.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message