Well now ... I think this post goes a bit far. At least he tried the task before
advocating it. The fact is that a large number of people poorly use StringBuffer
anyway. This could account for performance hits. The simple line of code that
you see all the time like:
StringBuffer buf = new StringBuffer(500);
buf.append("This is a test under " + System.getProperty("os.arch") +
" operating system, version " +
System.getProperty("os.version"));
This code has a serious problem. Since you are so busy calling others idiots,
can you tell us all why ?
-- Robert
"Chris Duprat" <[EMAIL PROTECTED]> wrote in message
005001c2d76c$a542bf50$8dfb0d50@zzz">news:005001c2d76c$a542bf50$8dfb0d50@zzz...
> Wasting of time. You shouldn't have the idea of implementing a pool for such
> objects because of their high availability. By adding another level you just
> reach the performance issue which is critical for that kind of objects.
>
> You're an Idiot ;-)
> http://www.pagetutor.com/idiot/idiot.html
>
> Cheers,
> Chris
>
> ----- Original Message -----
> From: "Lester Ward" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 18, 2003 4:19 PM
> Subject: StringBuffer pools and why not to use them
>
>
> > 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:
> >
> > http://www.divnull.com/lward/personal/writing/stringpool.html
> >
> > Comments welcome.
> >
> > ---------------------------------------------------------------------
> > 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]
