string buffer vs string builder in java
hi,
What are advantages, disadvantages, practical uses of each of
string buffer vs string builder in java vs + operator vs concat metjod of string
Please advise. Any ideas, resources, sample code highly appreciated. thanks in advance
What are advantages, disadvantages, practical uses of each of
string buffer vs string builder in java vs + operator vs concat metjod of string
Please advise. Any ideas, resources, sample code highly appreciated. thanks in advance
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
you must have been surely doing millions of String operations to notice any significant impact?
No not necessarily. The performance hit comes from the extra calls to "synchronize" that are used by the StringBuffer api.
So using the code that includes explicit calls to StringBuffer in a multi-threaded application could cause it to run 2x slower (or worse) than the same code using StringBuilder. That's because each call to synchronize essentially forces a memory synchronization event (so that all threads running on all CPU cores see the same state of main memory) - which in turn could limit the parallelism of the process as a whole or impact the CPU's cache performance.
So it's not the cost of the operation itself that's the issue - but the potential impact that could have on a larger multithreaded operation through hidden and unnecessary synchronization events.
On a single threaded program then it's fair to say the difference would be negligible (indeed it might be zero - not sure if there's any cost when there is no synchronization occurring?).
Doug
P.S. And yes I included a typo in my original code. It should be StringBuffer on both sides...
Yes, it's always good to be faster, and two times faster is of course better. But in practical terms it is not quite so outstanding - Buffer and Builder share the same order of magnitude base, and although if you extrapolate my code's results you get nearer to a fourfold slowdown if you consider about a 1 second delay as being the first appreciable deficit amount, then you would notice only about a one-and-a-half second lag between the two methods over a distance of 3 million append()(s) - enough to process each word in "War and Peace" 6 times over.
One would only want to use a synched approach if you needed that as such of course, but in sheer linear processing there's not much loose change.
One would only want to use a synched approach if you needed that as such of course, but in sheer linear processing there's not much loose change.
ASKER
I ran the program got output
Buffer ops took 268234080(---->9 digit huge number)
Builder ops took 23028845(---->8 digit number way smaller than buffer)
Char array ops took 10564509(---->8 digit number almost half of above builder number)
String concat took 4593848 nanosecs to produce a string of length 10000000
In above lines, I wonder how are we are we able to call sm.sb, sm.sbldr since sb, sbldr etc are neither method names nor static variables.
I also wonder what we are trying to do in above two lines and as a whole what we are trying to prove in this program, Please advise
Buffer ops took 268234080(---->9 digit huge number)
Builder ops took 23028845(---->8 digit number way smaller than buffer)
Char array ops took 10564509(---->8 digit number almost half of above builder number)
String concat took 4593848 nanosecs to produce a string of length 10000000
sm.sb = new StringBuffer(loops);
sm.sbldr = new StringBuilder(loops);
sm.chA = new char[loops];
In above lines, I wonder how are we are we able to call sm.sb, sm.sbldr since sb, sbldr etc are neither method names nor static variables.
halfString = sm.sb.substring(0,sm.sb.length()/2). toString() ;
otherHalfString = sm.sb.substring((sm.sb.length()/2)). toString() ;
I also wonder what we are trying to do in above two lines and as a whole what we are trying to prove in this program, Please advise
gudii9 -
sm is an instance of the StringMeter class, so it has the member vars of its class - the StringBuffer and StringBuilder. These are simply being accessed via the "." notation.
As for the concat(), this is just using the two halves of a large 1MB string which has already been created, and putting them back together again. It's only a loose use case which says that if you can achieve the concatenation of two such large chunks in that space of time, then use the result to estimate how that stacks up against other ways of doing the same thing. You could experiment with your own strings of different lengths to see what timings they give you for example.
The main focus of my comment and code was to obtain some ball-park comparisons between Buffer and Builder performance to help you in your question. But as Doug has said, there may be other considerations you need to take into account as well, and not just these crude timings.
sm is an instance of the StringMeter class, so it has the member vars of its class - the StringBuffer and StringBuilder. These are simply being accessed via the "." notation.
As for the concat(), this is just using the two halves of a large 1MB string which has already been created, and putting them back together again. It's only a loose use case which says that if you can achieve the concatenation of two such large chunks in that space of time, then use the result to estimate how that stacks up against other ways of doing the same thing. You could experiment with your own strings of different lengths to see what timings they give you for example.
The main focus of my comment and code was to obtain some ball-park comparisons between Buffer and Builder performance to help you in your question. But as Doug has said, there may be other considerations you need to take into account as well, and not just these crude timings.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@ by: TamilarasiSivarajPosted on 2013-10-24 at 08:56:14ID: 39596494
girionis already made this point.
girionis already made this point.
BTW I just thought of perhaps a clearer way to explain the potential impact of using StringBuffer in a multithreaded application.
It's like if you were running a team race around a track and you need all members of your team to get to the end in order to finish - last one over the line is your time (this is how bike races work!).
If you use StringBuilder then all members of the team put their heads down and go as fast as they can (no "synchronize").
If you use StringBuffer then after each step or turn of the wheel everyone looks up and has to look to see where each of their teammates is now and then continues on (we're using "synchronize").
As you can imagine, the team with all that checking will be slower to get to the end of the race. The more folks on your team, the worse it gets (everyone has more foks to check on). They don't have to necessarily wait for each other at each step, but all of that checking and verifying slows the team as a whole down (Java memory model and synchronize behavior).
OK - maybe that's no clearer :)
But I think it is the practical key difference here.
Doug
It's like if you were running a team race around a track and you need all members of your team to get to the end in order to finish - last one over the line is your time (this is how bike races work!).
If you use StringBuilder then all members of the team put their heads down and go as fast as they can (no "synchronize").
If you use StringBuffer then after each step or turn of the wheel everyone looks up and has to look to see where each of their teammates is now and then continues on (we're using "synchronize").
As you can imagine, the team with all that checking will be slower to get to the end of the race. The more folks on your team, the worse it gets (everyone has more foks to check on). They don't have to necessarily wait for each other at each step, but all of that checking and verifying slows the team as a whole down (Java memory model and synchronize behavior).
OK - maybe that's no clearer :)
But I think it is the practical key difference here.
Doug
BTW this : String msg = new StringBuffer() ; can't of course compile.