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