Very similar to the .clone() guidelines.
> -----Original Message----- > From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 18, 2003 1:18 PM > To: Jakarta Commons Users List > Subject: Re: StringBuffer pools and why not to use them > > > > In message <0C072E7CC947D511AC9600A0CC734120885E2B@XEON400>, > Lester Ward writes > : > >I was doing some performance tuning recently and thought to > try pooling > >StringBuffers. I built a pool for them based on > StackKeydObjectPool. Bad > >idea. Here is why: > > A number of Java performance rules of thumb seem to have been > invalidated > by the latest HotSpot releases. I can't give you the exact reference > off the top of my head, but the HotSpot team actually recommends that > programmers avoid object pools altogether now and to trust the memory > allocation and garbage collection system to perform efficiently. Your > experiment appears to support this recommendation. I have not taken > the time to investigate the situation in detail, but my > general impression > is that pooling objects simply to avoid the cost of memory > allocation may > well not be a win in many cases with the HotSpot runtime that > accompanied > J2SE 1.4. However, pooling objects whose creation or > initialization incur > additional costs beyond simple memory allocation--such as database > connections, threads, and network connections--is still a major win. > There is also evidence that pooling simply to avoid the cost of memory > allocation provides major benefits in programs that use many threads > running on multiple processors. The memory allocation system > is serialized > (or at least it was; I vaguely recall plans to parallelize it), which > creates a major bottleneck in concurrent programs. Pooling sidesteps > this problem. > > The real performance benefits of the changes introduced in the latest > versions of the HotSpot runtime (it's not just a JIT) are still poorly > understood, so you have to test things out to gauge the efficacy of > optimization techniques that used to be no-brainers. > > daniel > > > > --------------------------------------------------------------------- > 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]
