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

Louis Wasserman lowasser at google.com
Mon Sep 8 22:58:05 UTC 2014

FWIW, Google has gotten noticeable performance benefits from a change to
javac's compilation of normal + concatenation, to just presize the
StringBuilder.  I haven't had the bandwidth to forward-port that change
yet, unfortunately, but that's a semantics-preserving change that seemed to
us to be within spec.

On Mon, Sep 8, 2014 at 10:50 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> 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.
> -- 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.

Louis Wasserman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140908/cf2bc5db/attachment.html>

More information about the compiler-dev mailing list