Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

[Sergey Bylokhov]

On 08.09.2014 21:50, Jonathan Gibbons wrote:
> Yes, but is this really a big enough performance and footprint pain 
> point to be worth addressing in javac itself?
>
> We're now talking about some specific code construction like
>     new StringBuilder().append(a + b + c)
>
> Any other case where the string builder can be observed externally 
> cannot be subject to the proposed optimization. The use case is now 
> really getting pretty specific.
Not so specific at least in jdk code:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028142.html
>
> -- Jon
>
> On 09/08/2014 10:41 AM, Guy Steele wrote:
>> Good point, but counterpoint: it might be acceptable to have modified 
>> the string buffer in situations where throwing an exception would 
>> always cause the string buffer to become inaccessible.
>>
>> —Guy
>>
>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com> wrote:
>>
>>> It would be inappropriate/incorrect to apply the optimization as 
>>> described.
>>>
>>> The JLS requires that the argument to a method call should be 
>>> computed before invoking the method.
>>>
>>> Consider the case when one of the expressions in the series of 
>>> string concatenations throws an exception. It would be incorrect to 
>>> have already partially modified the string buffer.
>>>
>>> -- Jon
>>>
>>> On 08/29/2014 01:53 PM, Ulf Zibis 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 at 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.Zibis at 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.Zibis at 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.
>


-- 
Best regards, Sergey.