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 92065 invoked from network); 18 Feb 2003 17:54:14 -0000 Received: from smtp-out-4.wanadoo.fr (HELO mel-rto4.wanadoo.fr) (193.252.19.23) by daedalus.apache.org with SMTP; 18 Feb 2003 17:54:14 -0000 Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto4.wanadoo.fr (6.7.015) id 3E0C33FD021BACE0 for commons-user@jakarta.apache.org; Tue, 18 Feb 2003 18:54:17 +0100 Received: from zzz (80.13.251.141) by mel-rta8.wanadoo.fr (6.7.015) id 3E26DA70012B16D1 for commons-user@jakarta.apache.org; Tue, 18 Feb 2003 18:54:17 +0100 Message-ID: <00d001c2d776$c6f2f840$8dfb0d50@zzz> From: "Chris Duprat" To: "Jakarta Commons Users List" References: <0C072E7CC947D511AC9600A0CC734120885E2B@XEON400> <005001c2d76c$a542bf50$8dfb0d50@zzz> Subject: Re: StringBuffer pools and why not to use them Date: Tue, 18 Feb 2003 18:54: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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Well said, First allocation : 500 is too big Second Concatenation : it take more time to concatenate string than append them! StringBuffer buf = new StringBuffer(124); buf.append("This is a test under "); buf.append(System.getProperty("os.arch") ); buf.append(" operating system, version "); buf.append(System.getProperty("os.version")); ----- Original Message ----- From: "Robert Simmons" To: Sent: Tuesday, February 18, 2003 6:13 PM Subject: Re: StringBuffer pools and why not to use them > 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" 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 > > > > Cheers, > > Chris > > > > ----- Original Message ----- > > From: "Lester Ward" > > To: > > 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: commons-user-unsubscribe@jakarta.apache.org > > > For additional commands, e-mail: commons-user-help@jakarta.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-user-help@jakarta.apache.org >