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.
The "lifetime of the object" is a tricky one :-) There are a lot of cases ( tomcat Request object, JST tags ) where the object can very well live as long as the server. In almost any program there are a set of objects that are used a lot - where the object can be made mutable and reused. For short span objects - I agree, GC is better. But again, in most cases "short lifespan" of an object is by programming it to be non-reusable, and with a bit of work you can make it long-lived. > 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 MimeHeaders in 3.2 had some performance problems, AFAIK we made a lot of changes ( in both 3.3 and 5.0 ) Costin > 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. > > Marc > >> -----Original Message----- >> From: Glenn Nielsen [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, July 08, 2003 9:25 AM >> To: Tomcat Developers List >> Subject: Object pooling performance >> >> Remy Maucherat wrote: >> > Bill Barker wrote: >> > >> >> Now, if we could only convince the Jasper developers of this ... ;-). >> > >> > >> > Tag pooling is definitely not the same situation and use case as >> > session pooling. Tag pooling *is* useful in many cases. >> > >> >> There are a number of things to consider when evaluating the performance >> of >> object pooling. >> >> The performance hit of obtaining/recycling an object can be greater than >> instantiating a new object, it depends on the JVM. >> >> But you also have to consider the impact on GC. One big impact on >> performance >> of Tomcat is the frequency of and the time it takes to do incremental and >> Full GC's. >> >> Full GC's can be especially nasty. In most JVM's a Full GC freezes >> processing of >> requests by Tomcat. I would rather have a slight performance hit from >> recycling objects >> than see the frequency of Full GC's increase and the time they take >> increase. >> >> I saw a huge performance boost when recycling of JSP custom tags was >> implemented in >> Jasper. Most of that performance boost comes from reducing the frequency >> and length >> of GC's. >> >> To collect GC data add the -verbose:gc arg to java when you start Tomcat. >> >> Regards, >> >> Glenn >> >> >> >> --------------------------------------------------------------------- >> 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]
