It's probably best to teach the JIT to handle more of these cases. The
reason is I don't think the longer compile time will be worth it
considering that, on a large codebase, there will inevitably be lots of
places where these patterns appear but have no dominance at runtime (either
because they're not called or called just a few times). Additionally,
these patterns are unlikely to appear in hot code paths; no matter what
type of concat/string building (practical) optimizations you do, that type
of code will kill performance. Assuming that's true, what's the value add
given the costs?
Sent from my phone
On Aug 29, 2014 4:54 PM, "Ulf Zibis" <ulf.zi...@cosoco.de> wrote:
> Hi compiler people,
>
> is there some chance that javac could be enhanced to optimize better as
> discussed in this thread? Than refactoring of up to now better readable
> code to ugly StringBuilder@append() code would be superfluous.
> I really like the String concatenation syntax, but unfortunately it often
> causes slower code and bigger footprint.
> Optimally javac would optimize mixed use of StringBuilder, StringJoiner,
> concatenation, toString(), append(String), append(Collection) etc. to a
> single StringBuilder instance, so that the resulting code, JITed or not,
> will have better performance.
> Additionally javac could guess a reasonable initial capacity from the
> given source code.
>
>
> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>
>> So it's not that the optimization fails but there is no optimization on
>> them yet.
>>
>> I do see the .append("x") case will be easy to deal with, but it looks
>> like historically javac has not been a place to do many optimizations. It
>> mostly converts the java source to byte codes in a 1-to-1 mapping and let
>> VM do whatever it wants (to optimize). When you talked about compiling
>> multiple concatenation into using a single StringBuilder, it's more like
>> choosing the correct implementation rather than an optimization.
>>
>> I don't expect to see big change on this in the near future, so shall we
>> go on with the current enhancement?
>>
>> Thanks
>> Max
>>
>> On Aug 29, 2014, at 2:17, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
>>
>> I mean:
>>> It does not output byte code that only uses a single char array to
>>> compose the entire String in question.
>>> With "optimization fails", I also mean, there is used an additional
>>> "StringComposer" e.g. another StringBuilder or a StringJoiner in addition
>>> to the 1st StringBuilder.
>>>
>>> -Ulf
>>>
>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>
>>>> Could you please explain what you mean by "javac optimization fails"
>>>> here?
>>>>
>>>> -Pavel
>>>>
>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
>>>>
>>>> 4.) Now we see, that javac optimization fails again if StringBuilder,
>>>>> concatenation, toString(), append(String), append(Collection) etc. and
>>>>> StringJoiner use is mixed.
>>>>>
>>>>
>>
>
