• Post Reply Bookmark Topic Watch Topic
  • New Topic

String Vs StringBuffer  RSS feed

 
Krishna Srinivasan
Ranch Hand
Posts: 1879
Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI,
Here i am facing some performance difference with String and StringBuffer.
Firts i tried using StringBuffer, execution time difference is 0 secods...that means its fast..but i tried using String class ...it gives 10 mili seconds diff in execution of the loop.....but its only the first time i am execting the program...second time its execute within 0 mili seconds .......
what is the reason ??


Sample.java
=========


DateFormat.java
===========


[added code tags - Ilja]
[ June 25, 2004: Message edited by: Ilja Preuss ]
 
Gian Franco
blacksmith
Ranch Hand
Posts: 979
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

How many times did you try this out,
do you have a representative amount
of test runs?

Cheers,

Gian Franco

ps I'm afraid this topic will be
moved from this forum
[ June 25, 2004: Message edited by: Gian Franco Casula ]
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right on. Moving to... Damn it. It's already here!
[ June 25, 2004: Message edited by: Barry Gaunt ]
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36453
459
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Windows, Java can only measure times 10 millis apart. Try putting the code in a loop and run it 100 times. Then you will get times you can compare.
 
Kris Philippaerts
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't forget, the java specification states that String concatenation will be optimized (where possible) by using StringBuffers. So, the performance of both pieces of code might be equal... You should first try to compile both pieces of code, and then decompile it, and see if the decompiled code still works with Strings.

Second, you should never trust time measurement under, say, 100ms on Windows. As stated before, try to run your test 100 times, or even 1000 times in a loop, and compare the total times.
 
Kris Philippaerts
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know, this thread might be dead allready, but what the heck I tried it out for you. I ran both implementations 100,000 times and measured the time needed for this. The String implementation took 1.482 seconds to complete. The StringBuffer implementation took no more than 270 milli seconds to complete. This is more than 5 times faster than the String implementation.

 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much!

Can you show us the benchmark code?

Also, what JDK did you run this on? This might heavily affect performance differences.
 
clio katz
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in all of the performance doc i have read, StringBuffer is (almost) always recommended over String ... particularly for operations involving string concatenation

to wit
Adding on to a StringBuffer is [also] quite a bit faster than the + operator, which creates a new StringBuffer itself, appends both of the arguments, and converts the result back to a String

- patrick.net

some other linx

Glen McCluskey et al
Hardwick's Java Optimization site

[these sites also have additional embedded links as well]


hth
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in all of the performance doc i have read, StringBuffer is (almost) always recommended over String

Well not really. However in cases where String + is faster, it's usually a very minor difference. In cases where StringBuffer is faster, it may be much, much faster. Adding N things to a StringBuffer is an O(N) operation. Adding them to a String via concatenation can be an O(N^2) operation. Which is a Bad Thing™ if N is big.

A good general rule of thum is: if you're adding to a stringlike thingy inside a loop, and the thingy gets bigger each time - use a StringBuffer. Otherwise, use String coincatenation with the + sign. The difference in performance is minor, and the + is usually more readable.


For what it's worth, if you can build up the entire String in one line, no loop, then the + will generally be at least as fast as using a StringBuffer. And if everything in the expression is a compile-time constant, then using + is almost certainly faster than StringBuffer, because all the work will be done at compile time.
 
Kris Philippaerts
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Can you show us the benchmark code?

Also, what JDK did you run this on? This might heavily affect performance differences.


I just took Krishna Srinivasan's code and cleaned it up a bit. I'm not sure what JDK I used at home. But I tried it again at work with JDK 1.4.2_03 (on a faster PC that at home). These are the results:



So, the -O option doesn't do much. The ratio of 5 times faster holds.

Grtz,
Kris


Sample.java


DateFormatString.java


DateFormatStringBuffer.java
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for sharing the code!

One more tip: an important thing to do is to try wether swapping the order of execution, that is executing the StringBuffer version before the String version, makes a difference. It *could* have an impact because of incremental optimizations done by the Hotspot Engine.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
FYI, I just tried swapping the order, and it doesn't make a difference.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!