I believe yes.
Using the -XX:+OptimizeStringConcat:
java -jar -XX:+OptimizeStringConcat target/microbenchmarks.jar
.*StringBuilderConcatBenchMark.* -wi 10 -i 10 -f 1
The same thing happened:
Benchmark Mode Samples
Mean Mean error
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
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
Hi all,
a critical question!
1.) Why we have String concatenation in Java? ... I would answer: for
_readability_ purpose.
2.) In the early javac times, we were asked to refactor to StringBuffer for
performance critical code.
3.) Since 1.6 ? javac is capable to replace multiple concatenation
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
I filed a bug at
https://bugs.openjdk.java.net/browse/JDK-8038277
Webrev in 3 parts at
http://cr.openjdk.java.net/~weijun/8038277/client/webrev.00
http://cr.openjdk.java.net/~weijun/8038277/core/webrev.00/
http://cr.openjdk.java.net/~weijun/8038277/extra/webrev.00/
--Max
On Aug
https://bugs.openjdk.java.net/browse/JDK-8038277
This is not the right bug report. The subject of this bug report is
Improve the bootstrap performance of carets keystore.
http://cr.openjdk.java.net/~weijun/8038277/client/webrev.00
TABs are still used for indentation. I looked only
I had a random look at the Webrev for TreeModelEvent.java and saw the
following new code:
sb.append(Integer.toString(childIndices[counter]))
Wouldn't the following be slightly more efficient?
sb.append(childIndices[counter])
since Integer.toString(int) creates a temporary char[] array
Hi Martin,
you are right. And in the line 297:
297 sb.append(getClass().getName()).append('
').append(Integer.toString(hashCode()));
Integer.toString() can be removed too.
Best regards,
Andrej Golovnin
On Thu, Aug 21, 2014 at 3:26 PM, Martin Desruisseaux
On Aug 21, 2014, at 21:18, Andrej Golovnin andrej.golov...@gmail.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8038277
This is not the right bug report. The subject of this bug report is Improve
the bootstrap performance of carets keystore.
Oh, my mistake, it should be
I also see a lot of .toString() and String.valueOf() calls.
$ cat string_concat_updated.patch | perl -ne 'print if /^\+
.*append.*(String\.valueOf|\.toString\(\))/' | wc
62 2104626
Wrapped lines not indented correctly in
Brian,
Yes, this works fine in cases when 'whatever' is a j.u.Collection? extends
CharSequence (though some may argue that it's an overkill already). However we
need even more thinking and transformations in case when 'whatever' is one of
these:
* j.u.Iterator? extends CharSequence
*
Hi Otávio,
The new alignment in DataLine.java/JColorChooser.java looks strange.
Wrong change in BasicTableUI.java:
-plainStr.deleteCharAt(plainStr.length() -
1).append(\n);
+plainStr.deleteCharAt(plainStr.length() -
1).append('\t');
On 13.08.2014 3:01,
Hi Otávio
I see TABs in the first page of sun_security.diff, too long line in
javax_security.diff.
Also, it's unfortunate that you will need to rename the file names to the new
style with modules. See
http://cr.openjdk.java.net/~chegar/docs/portingScript.html for how to do this.
I can create
What you should have written was:
String s = whatever.stream().collect(joining(, ));
On 8/11/2014 1:31 PM, Pavel Rappo wrote:
Sorry, I should've written this:
Iterable? whatever = ...
StringJoiner joiner = new StringJoiner(, );
whatever.forEach(w -
Could anyone help me as sponsor, please?
On Tue, Aug 12, 2014 at 8:01 PM, Otávio Gonçalves de Santana
otavioj...@java.net wrote:
Thank you Roger.
Done
https://dl.dropboxusercontent.com/u/16109193/open_jdk/string_builder_concat_6.zip
On Tue, Aug 12, 2014 at 10:15 AM, roger riggs
Hi Otávio,
I think you should fix the indentation in a lot of classes. You use the
tab-character for the indentation. As far as I know we should use the space
character for the indentation in the JDK sources (Oracle devs feel free to
correct me if I'm wrong. And it would be really nice if the
fyi,
There's a Perl script normalizer.pl that detects/fixes most of the
simple tab/white space issues.
The script is in the repo/make/scripts/normalizer.pl
Roger
On 8/12/2014 3:48 AM, Andrej Golovnin wrote:
Hi Otávio,
I think you should fix the indentation in a lot of classes. You use the
Hi Otávio,
the class src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java is generated
from the grammar
src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.jjt
src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.jj
Therefore when you are going to change the Parser class, then you must
change the
In the class
src/share/classes/javax/management/openmbean/CompositeType.java you have
added the
annotation @SuppressWarnings(StringConcatenationInsideStringBufferAppend)
instead of fixing the concatenation inside the append method. Why?
+1 Moreover, I wonder where this value comes from? I've
Hi Otávio,
About the template in Parser.jjt, TokenMgrError.java, etc. I don't know how
can do that. Can anyone help me?
See attached diff for the changes in Parser.jjt and Parser.jj. For the
TokenMgrError and ParserException you can just subscribe here:
https://java.net/projects/javacc/lists
Hi Otávio,
please ignore the previous diff. I'm sorry, there was a small mistake. I
have attached the corrected version.
Best regards,
Andrej Golovnin
On Mon, Aug 11, 2014 at 1:55 PM, Andrej Golovnin andrej.golov...@gmail.com
wrote:
Hi Otávio,
About the template in Parser.jjt,
Hi,
About readable of code I just renamed this class to sb instead of buf,
strbuf, etc.
I doubt that renaming variables does really improve the code readability.
And you changed the indentation (take look at other classes too):
239 public String toString() {
240 StringBuilder sb
Hi Otávio!
A few days ago I've posted another cleanup request, which included
modifications to src/share/classes/sun/net/www/MimeEntry.java
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028131.html
As our changes overlap, one should be reverted back.
I believe using
Am 11.08.2014 um 15:12 schrieb Andrej Golovnin:
In the most classes I mentioned in my previous mail only the
#toString()-methods would be affected by the proposal. And in the most
cases, maybe in all cases, the #toString()-methods in this classes exists
only to provide nice output.
So why not
Otavio,
Just skimmed through your changes. It looks good. But there are some things we
can make a little bit better though. IMO, it's not always a performance that
matters (looking around to see if Alexey Shipilev is somewhere near) but
readability. It's good to estimate performance
Am 11.08.2014 um 16:33 schrieb Pavel Rappo:
Unfortunately, neither java.util.StringJoiner nor String.join have perfect (but
who has?) APIs. So it's up to us to figure out the best way of joining elements.
Maybe remember my thoughts from here:
Ulf,
My point was simply that none of these classes provide methods that accept
java.lang.Object. IMO, the scenario when we join elements into a String by
calling toString on each element prior to append it -- is the most common
scenario (maybe except for when element is a String itself). That
Sorry, I should've written this:
Iterable? whatever = ...
StringJoiner joiner = new StringJoiner(, );
whatever.forEach(w - joiner.add(w.toString()));
String s = joiner.toString();
-Pavel
On 11 Aug 2014, at 17:17, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi Otávio,
this is a great proposal.
Little nit:
In cases where only 1 character is to append, I guess append(char) would be faster and at least will
save footprint in contrast to append(String).
-Ulf
Am 10.08.2014 um 23:33 schrieb Otávio Gonçalves de Santana:
*Motivation:* Make another
+1
Some suggestions (mostly nits):
- in places like src/share/classes/java/util/regex/Pattern.java you
introducesingle-char
strings which might use a char instead:
-result.append(|+next);
+result.append('|').append(next);
- in places like
Am 11.08.2014 um 01:03 schrieb Claes Redestad:
- in places like src/share/classes/sun/security/provider/PolicyFile.java
you end up with a sequence of String literal appends which could be merged
into one:
-sb.append(principalInfo[i][0] + +
-\ +
32 matches
Mail list logo
