tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Saegesser <>
Subject RE: Object pooling performance
Date Tue, 08 Jul 2003 21:00:41 GMT
I agree that the MimeHeaders example is not really an example of an object
pool.  I used it because it was a recent example that I found where avoiding
GC at all costs was the wrong approach.  Keep in mind, the utils stuff that
I'm talking about is from TC3.2.  I haven't looked at the latest TC code so
it may be significantly better.  

The biggest problem with the TC3.2 MimeHeaders was that the algorithm
required a large number of string comparisons and the number of comparisons
increased geometrically as the number of headers increased.  Rewriting the
code to use a Hashtable and a better data structure for tracking headers
with multiple values provided a significant performance benefit even though
it created some garbage along the way.  

Since all of the objects were short lived, their allocation and collection
from the nursery was very efficient and was far faster than all the string
comparisons required by the original algorithm.

The original performance problem stood out quite well in JProbe.  The new
code profiled faster and was then verified under a load test using
real-world scenarios.


> -----Original Message-----
> From: Remy Maucherat []
> Sent: Tuesday, July 08, 2003 3:18 PM
> To: Tomcat Developers List
> Subject: Re: Object pooling performance
> 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
> comparison.
> 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.
> Remy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message