Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!news.netfront.net!not-for-mail From: Wanja Gayk Newsgroups: comp.lang.java.programmer Subject: Re: StringBuilder Date: Sun, 11 Sep 2011 16:35:55 +0200 Organization: Netfront http://www.netfront.net/ Lines: 62 Message-ID: References: <96f358c8-a024-40db-b60b-300186c2f813@o10g2000vby.googlegroups.com> <4e655caa$0$308$14726298@news.sunsite.dk> NNTP-Posting-Host: 77.177.187.230 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: adenine.netfront.net 1315751828 71643 77.177.187.230 (11 Sep 2011 14:37:08 GMT) X-Complaints-To: news@netfront.net NNTP-Posting-Date: Sun, 11 Sep 2011 14:37:08 +0000 (UTC) User-Agent: MicroPlanet-Gravity/3.0.4 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7798 In article <4e655caa$0$308$14726298@news.sunsite.dk>, arne@vajhoej.dk says... > > Whereby this code is slower: > > > > String res=""; > > for (int i=0; i<100; i++) { > > res+=i+"*"+i+"="+(i*i)+"\n"; > > } > > System.out.println(res); > > > > It is translated to the following code by the compiler, and > > thus uses 100 new and 100 toString(): > > > > String res=""; > > for (int i=0; i<100; i++) { > > StringBuilder _buf=new StringBuilder(res); > > _buf.append(i); > > _buf("*"); > > _buf.append(i); > > _buf.append("="); > > _buf.append((i*i)); > > _buf.append("\n"); > > res=_buf.toString(); > > } > > System.out.println(res); > > > > For more information see for example here: > > http://caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/ > > That has been known for 10-15 years. > > It should be in any Java book above beginners level. Like other ancient performance-practices that have been obsoleted by today's compilers? We have been told that using StringBuffer was the better alternative. Now compilers have switched from using StringBuffer for the above example to the unsynchronized StringBuilder. Those who have manually used the StringBuffer have stopped the compiler for doing that for them and must rely on the JITs lock elision algorithm. So as long as this part of the code does not represent a critical performance-bottleneck, I would recommend to use the simple, stupid "slow" variant and hope for future compilers to detect and optimize that pattern. > http://java.sun.com/developer/technicalArticles/Interviews/community/k abutz_qa.html < Kind regards, Wanja -- ..Alesi's problem was that the back of the car was jumping up and down dangerously - and I can assure you from having been teammate to Jean Alesi and knowing what kind of cars that he can pull up with, when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer] --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---