Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Jan Burse Newsgroups: comp.lang.java.programmer Subject: Re: StringBuilder Date: Sun, 18 Sep 2011 09:54:41 +0200 Organization: albasani.net Lines: 64 Message-ID: References: <96f358c8-a024-40db-b60b-300186c2f813@o10g2000vby.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net g4UNZ6Xs7rjsg9VMydPJjitAUkPuLWAx08ftQLJa1j63XcwFqA/vjNeebL5nHzoCIbbhUJp1tWYuBiNpT8ogIw== NNTP-Posting-Date: Sun, 18 Sep 2011 07:54:42 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="R0/SpJQbRQZTSSdlCg646SdlicuYqIDQ0PcqSwISK1f9b2S5v3KljsNEEnkMowojoXS+hmpnmbCP/oj9MkeFw4jArurqp1mbpQU6EEYGVJSddCSQoJlhCmrE/qf4yWlF"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 In-Reply-To: Cancel-Lock: sha1:kvo/iJwt0oKMAA0PRe2yuUU2fjA= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8118 Peter Duniho schrieb: > In any case, if Java does _not_ implement it that way, I suspect that's Well, I wouldn't say its a matter of *Java*. Its a matter of the given JDK how it is implementented. *Java* defines the contract but there are many implementations. From my post you can read off the following findings: Oracle: Always does a copy (I only checked rt.jar, not some alt-rt.jar). OpenJDK: Always does a copy. Harmony: Most of the time does a sharing and flags the builder (Similarly like you describe the .NET implementation) But beware the list is not complete, for example I didn't check the Apple classes.jar or IBM's rt.jar. And also the finding only holds for JRE 1.6, and can change at any time if the provider of the JRE decides so. Or might be different for 32-bit and 64-bit etc.. > different decision-making process rather than ignorance. In other > words, they have already considered whether it's a worthwhile > optimization and decided There is not only a plurality of *they* as can be seen from above, but there is also a plurality what means *worthwhile*. An implementation with a more reference implementation character, like for example the Oracle JRE, might take the simple route. Since the focus is then more on functional requirements than on non- functional requirements. > Which strongly suggests that anyone worrying a priori > about the performance of StringBuilder before they have > demonstrated it's an actual bottleneck in their program > is wasting their time. I guess it is more about performance tuning than removing bottlenecks. And any performance gain is only seen in programs that make heavy use of StringBuilder. Such measurements have already been done over and over. See for example (not exactly measurig toString()): +=: 546 ms StringBuilder, default initial capacity: 30ms StringBuilder, exact initial capacity: 10ms http://christian.bloggingon.net/archive/2008/09/06/performance-vorteile-bei-der-verwendung-von-stringbuilder.aspx But measurements in detail will vary depending on JDK and machine. But whether one JDK changes the measurment fundamentally depends very much of the available algorithms for the functional requirements and how these algorithms behave non-functionally. But I would say the consumers of JDKs are we the programmers, so it is good to measure, inspect and debate JDKs and not blindly trust any *they*. Bye