Question about StringBuffer efficiency

[Tom Blough]

What is more efficient:

buffer.append( String1 + String2 + String3);

or

buffer.append( String1);
buffer.append( String2);
buffer.append( String3);

Does it make any difference in the above examples if any/all of the strings is/are string literal(s)?

TIA,
[ August 18, 2005: Message edited by: Tom Blough ]

[Norm Radder]

Write a test program with a loop to do your code thousands of times and time it. Run the test hundreds of times to smooth out any system interruptions.
Analyze the results and Post the results here.
Then we'll all know.

[Ernest Friedman-Hill]

It does make a difference if they're all literals; if they are, the "+" can be done by the compiler, so at runtime there's just one String to append; that makes the + version a bit more efficient.

If they're not then the three-append version is better; the +'s will be compiled into the creation of another StringBuffer and some more append calls.

I don't really recommend trying to micro-benchmark this yourself, for the simple reason that any differences will be so small they'll be hard to measure. This really doesn't make a whole lot of difference in most cases.

[Tom Blough]

Thanks, Ernest.

That's kinda what I though, but I didn't know if there was a clear winner. To me, both versions seem just as clear from a readability standpoint, so I guess I'll continue to use the concatination version as there is less typing required.

Norm, if I had time, I'd code it an test it, but nobody is paying for that, so it will have to wait.

Cheers,

[Tony Morris]

Ernest actually meant "constant", not "literal", though you'll find a significant performance degradation (I've see an order of magnitude of about 15000) if you append non-constants within a loop. The million dollar question is why? I'll leave you to ponder.

In any case, design first, optimise later - as long as you have a robust regression, this is a trivial implementation issue compared to many other potential issues - spend 95% of your effort on ensuring the integrity of your contracts, since this is the part that cannot change. The biggest mistake I see is not clarifying the distinction between contract and implementation - for example, even as much as a non-private constructor is enough to expose unnecessary implementation detail.

[Ilja Preuss]

Originally posted by Tom Blough:

buffer.append( String1 + String2 + String3);

If the Strings aren't compile time constants, this is equivalent to

buffer.append(new StringBuffer().append(string1).append(string2).append(string3).toString());

[Stefan Wagner]

buffer.append( String1 + String2 + String3);

If the Strings aren't compile time constants, this is equivalent to

buffer.append(new StringBuffer().append(string1).append(string2).append(string3).toString());

[/qb]
I don't think so.
String1+String2+String3 is evaluated first, which is creating implizit new Strings first (String1+String2), ((String1+String2)+String3), before StringBuffer.append is called for that generated new String.
[ August 19, 2005: Message edited by: Stefan Wagner ]

[Stefan Wagner]

 
Iterations:  50000000   PerformanceTest StringBufferAgain
switching to jdk-1.4
mode client:
true            real    0m12.684s       user    0m11.808s       sys     0m0.396s
false           real    0m20.940s       user    0m19.580s       sys     0m1.270s
mode server:
true            real    0m6.575s        user    0m6.122s        sys     0m0.384s
false           real    0m14.371s       user    0m12.464s       sys     0m1.224s
switching to jdk-1.5
mode client:
true            real    0m13.826s       user    0m11.862s       sys     0m0.398s
false           real    0m21.093s       user    0m19.780s       sys     0m1.204s
mode server:
true            real    0m6.575s        user    0m6.144s        sys     0m0.386s
false           real    0m13.852s       user    0m12.523s       sys     0m1.247s

The benchmark suggests that the form 'false' (2x +) needs 1.5 to 2-times the time compared to 'true' (3x append).
And the second suggestion: You get about 5 million calls per second on my machine.

It's not science-solid-measurement, but my experience shows, that I can rely on the results, if the amount of time is greater than a second, and the differences are greater than 20%.
[ August 19, 2005: Message edited by: Stefan Wagner ]

[Rick O'Shay]

Side note: use StringBuilder in 5.0 and serialize access to the object when the need arises. Since 5.0 I use StingBuffer precisely never, 'least not to new code.

[Ronnie Ho]

Originally posted by Stefan Wagner:

buffer.append( String1 + String2 + String3);

If the Strings aren't compile time constants, this is equivalent to

buffer.append(new StringBuffer().append(string1).append(string2).append(string3).toString());

I don't think so.
String1+String2+String3 is evaluated first, which is creating implizit new Strings first (String1+String2), ((String1+String2)+String3), before StringBuffer.append is called for that generated new String.

[ August 19, 2005: Message edited by: Stefan Wagner ][/QB]

I think the compiler automatically translates the + operator into StringBuffer.append() even before the code is executed by the JVM execution engine. So, the compiler indeed interprets

  buffer.append( String1 + String2 + String3); 

AS

  buffer.append(new StringBuffer().append(string1).append(string2).append(string3).toString());

[Ilja Preuss]

Originally posted by Ronnie Ho:
I think the compiler automatically translates the + operator into StringBuffer.append() even before the code is executed by the JVM execution engine. So, the compiler indeed interprets

  buffer.append( String1 + String2 + String3); 

AS

  buffer.append(new StringBuffer().append(string1).append(string2).append(string3).toString());

[/QB]

According to the JLS 15.18.1.2, the compiler *is allowed* to do so. As far as I know, all current compilers do.

[Tony Morris]

the 1.5 compiler doesn't

[Ilja Preuss]

Originally posted by Tony Morris:
the 1.5 compiler doesn't

Good catch. It uses StringBuilder (?) instead, doesn't it? Of course that doesn't change the argument...

[Tony Morris]

Well, since I work on *the* 1.5 implementation as my regular job, and it hasn't been released yet, I'm not at liberty to say But if you're referring to the Sun implementation, last I looked, it uses java.lang.StringBuilder; yes, your point still stands.