Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

[Vitaly Davidovich]

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
>
>