Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Tue Feb 12 00:45:57 UTC 2013

javac will not replace concat ops across loop iterations, it will replace whichever ones are inside one loop iteration. This will still create temporary StringBuilder instances.

As for JIT optimizing further, it would have to fully unroll the loop to have a chance at eliminating this; I'd be really surprised if loops with nontrivial (and non compile time constant) trip counts get eliminated. I'd also not rely on JIT here and do the "right" thing manually :). You also may not have C2 compiler available or may not even be running on hotspot.

Sent from my phone On Feb 11, 2013 7:21 PM, "Ulf Zibis" <Ulf.Zibis at cosoco.de> wrote:

Am 11.02.2013 22:26, schrieb Hildeberto Mendonça:

Hello Ulf,

On Mon, Feb 11, 2013 at 9:03 PM, Ulf Zibis <Ulf.Zibis at cosoco.de <mailto:_ _Ulf.Zibis at cosoco.de>> wrote:

Hi Hildeberto, maybe your believe is correct. You could have a look in the byte code by javap. And additionally you could run a benchmark for both alternatives and compare, if HotSpot compiler would be able to optimize both with same result. I would like to know the result :-) -Ulf The issue is fairly documented in the book "Effective Java - Second Edition" by Joshua Bloch, pg. 227: "Item 51: Beware the performance of string concatenation". It gives an example with a "for" saying that "The difference in performance is dramatic." The method with StringBuilder "... is eighty-five times faster than... " the one with String concatenation considering only 100 iterations. Hi again, I suspect, "Effective Java" was written some time before javac substituted string concatenation by StringBuilder calls, and before HotSpot optimizations were as performant as they are today. I'm still inquisitive about some micro-benchmark results. -Ulf

More information about the core-libs-dev mailing list