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.gibb...@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.gibb...@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@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.
>>>>>>>>
>>>>>>>
>
--
Louis Wasserman
