Re: StringBuilder
Wanja Gayk wrote:
ar...@vajhoej.dk says...
It should be in any Java book above beginners level.
Like other ancient performance-practices that have been obsoleted by
today's compilers?
No.
What we are talking about is the "+=" part and that part is
still relevant for todays compilers.
And "still" is the keyword. The question remains: For how long will this
hold true?
You said "today's compilers".
Actually JB's example use = but to be equivalent to the first code
the it need to be +=.
And besides what he mention as reasons there are also
the 100 new strings.
So what's the problem with these? before answering, just have a look at
this:
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
That tells part of the story, but extra objects still cause both memory and time overhead. Time comes from GC cycles that kick in because you were profligate.
....[snip] ...
Nope, I'm arguing that:
String x="";
for(String s : strings){
x+=s;
}
or
String x="";
for(String s : strings){
x=x+s;
}
Is simple pattern that could be detected by tomorrows JIT-compilers and
But you changed your argument. You _were_ speaking of "today's compilers". Now suddenly you're speaking of "tomorrows [sic] JIT-compilers".
Besides shifting your ground, you have weakened your argument. It's one thing to program to allow "tomorrow's compilers" to further optimize your code, it's quite another to program to *require* "tomorrow's compilers" to further optimize your code.
You don't know for a fact that "tomorrow's compilers" will ever optimize across multiple lines of 'String' concatenation.
As you say, they "could be" able to do that; you just cannot aver that they will be able to do that.
But of course, that's only now that you've moved the discussion from "today's compilers" as you first said, to "tomorrow's compilers" as you now wish to discuss.
transformed into:
StringBuilder b = new StringBuilder();
for(String s : strings){
b.append(s);
}
String x = b.toString();
But I don't think any compiler programmer would care to detect this
pattern:
StringBuffer b = new StringBuffer ();
for(String s : strings){
b.append(s);
}
String x = b.toString();
Just to transform it into the the StringBuilder-variant.
That would likely be incorrect anyway, since the semantics differ. Of course, "tomorrow's JIT compiler" could figure out that there's no thread leak, so it "could be" able to do it. Maybe.
--
Lew