Bernd Fondermann wrote:
On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
----
Output code 2 from jdk 1.4
> String s2 = s + "test" + s1 + "test" + i;
----
Output code 2 from jdk 1.5
> String s2 = (new StringBuilder()).append(s).append("test")
> .append(s1).append("test").append(i).toString();
I also ran with jdk5 that code in a loop of 1 million iterations using
foo = "foo" and bar = "bar" (this is FAR from any realistic scenario).
<sigh> Microbenchmarking, again! ;-)
Could it be you are testing loop optimization here? ;-)
I started the message with a worning about this ;-)
Anyway I did a lot of micro changes to try to understand wether the
microtest was realistic or not. As an example if I concatenate 2 more
tokens in the same line the resulting time is increased by 30%. I also
increased and decreased the loop count and randomly generated the
contents of the variables. Times was always comparable: +/- 20%
What also is totally obscured by the whole discussion, is to set in
relation the max performance difference of the different logging
implementations discussed here - the "delta" - to the cost of the
rest of the method. Only if delta is a significant cost (a "hot spot")
it is worth talking about optimizing it before optimizing everything
else.
Bernd
I agree on this.
I just wanted to show more detail about the "old good practices" we all
know vs new jvm/jdk.
Imho it is really interesting to see that in jdk 1.5 the string
concatenation is replaced by StringBuilder by default and this way is
even better than using the StringBuffer.
To me this mean: using StringBuilder make my code to require java 5,
using StringBuffer make my code to work better on java 2 1.4, worse on
java 5, using String concatenation make my code to work best if I
compile/run with java 5, otherwise it perform a little worse, but very
little in java 2 1.4+.
I've not found papers/test on the web about this issue, I did it, I had
an unexpected result. Maybe you all know about this optimizations in
java5, but now I will use pure string concatenation much more.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
