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.
