Return-Path: Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 16121 invoked from network); 18 Feb 2003 18:43:38 -0000 Received: from mx12.arcor-online.net (151.189.8.88) by daedalus.apache.org with SMTP; 18 Feb 2003 18:43:38 -0000 Received: from robertgame (dsl-212-144-221-232.arcor-ip.net [212.144.221.232]) by mx12.arcor-online.net (Postfix) with SMTP id 4B2D9E5606 for ; Tue, 18 Feb 2003 19:43:41 +0100 (CET) Message-ID: <09e401c2d77d$c2bb3dd0$0100a8c0@robertgame> From: "Robert Simmons" To: "Jakarta Commons Users List" References: <0C072E7CC947D511AC9600A0CC734120885E2B@XEON400> <005001c2d76c$a542bf50$8dfb0d50@zzz> <3E527487.6@altern.org> Subject: Re: StringBuffer pools and why not to use them Date: Tue, 18 Feb 2003 19:44:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Jerome Lacoste @ BBC" 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" 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 ;)