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. Marc > -----Original Message----- > From: Remy Maucherat [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
