commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <deri...@arcor.de>
Subject Re: StringBuffer pools and why not to use them
Date Tue, 18 Feb 2003 18:44:25 GMT

----- Original Message -----
From: "Jerome Lacoste @ BBC" <lacostejbbc@altern.org>
Newsgroups: gmane.comp.jakarta.commons.user
Sent: Tuesday, February 18, 2003 6:59 PM
Subject: Re: StringBuffer pools and why not to use them


> Robert Simmons wrote:
>
> >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 ?
> >
> There are two bad things:
> - too much allocation

Depends on what you are doing afterward. Reallocating the buffer is
expensive. If you expect to do hundreds of appends (such as in a loop or when
dumping an object to XML) you want the buffer to ideally never have to be
resized. The question you address is what is the optimal size for the
operation.

> - no use of the append() methods
>
> Both make the calls slower. On my machine, reducing the size of the
> StringBuffer to 80 (*) helps as much as using append() correctly.
>
> (*) could have used a different value there. Just knowing that doMe()
> returns a String of length 54 on my VM
>
> Looping 100000 times around a call to these methods
>
>   public static String doMe()
>   {
>     StringBuffer buf = new StringBuffer(500);
>     buf.append("This is a test under " + System.getProperty("os.arch") +
>                       " operating system, version " +
>     System.getProperty("os.version"));
>     return buf.toString();
>   }
>
>   public static String doMeBetter()
>   {
>     StringBuffer buf = new StringBuffer(500);
>     buf.append("This is a test under
> ").append(System.getProperty("os.arch"));
>     buf.append(" operating system, version
> ").append(System.getProperty("os.version"));
>     return buf.toString();
>   }
>
>   public static String doMeEvenBetter()
>   {
>     StringBuffer buf = new StringBuffer(80);
>     buf.append("This is a test under
> ").append(System.getProperty("os.arch"));
>     buf.append(" operating system, version
> ").append(System.getProperty("os.version"));
>     return buf.toString();
>   }


If anyone wrote chained code like that for me, Id beat them with a stick.

Other than that, this is a simplistic example. You cant do the same thing in
a for loop or, for that matter, most of the time. There would likely be a
logic between each of those appends.

>
> Results:
>
>
> DoMe() count: 4500
> DoMeBetter() count: 3234
> DoMeEvenBetter() count: 1704
> DoMe() count: 4500
> DoMeBetter() count: 3218
> DoMeEvenBetter() count: 1703
> DoMe() count: 4563
> DoMeBetter() count: 3203
> DoMeEvenBetter() count: 1734
>
> >-- Robert
> >
> >"Chris Duprat" <christopher.duprat@wanadoo.fr> wrote in message
> >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
> >>
> BTW, click on on the page anywhere, drag your mouse over the button and
> release click at once to win ;)


Mime
View raw message