We help IT Professionals succeed at work.

String concatenation and Stringbuider which one is the faster.

srikotesh
srikotesh asked
on
Hi Experts,

String concatenation and Stringbuider which one is the faster.
what is the better appraoch to use while framing queries.

String concatenation will create one object or multiple?(I guess it will create one object).

example:

String concatenation:
=================
String query = select * from testsample where testsample_id='"+id+"'
                          +" and name='"+name+"'
                          +" and deleteflag ='"+N+"'

StringBuilder :
===========
StringBuilder sb = new StringBuilder();
sb.append("select * from testsample where testsample_id='"+id+"'");
   .append("and name='"+name+'"");
   .append("and deleteflag ='"+N+'"");

Open in new window

Comment
Watch Question

masheikSoftware Engineer

Commented:
I think using ORM is somewhat slower than direct query execution since , it has it is own construction and logic behind to do so along with your piece of code.
String concatenation is faster.

This is because the compiler can optimize your code to do whatever it wants.  It can use a StringBuilder (same speed) or it could pre-compute the result (much faster) or it could use a new, faster way to combine strings in the next version of the compiler which doesn't even exist today.

In all cases, this means it will be either faster or the same speed.

So use string concatenation for building up simple strings like this.  The only time to use StringBuilder is when you're looping through a collection of values and adding them together (i.e. the string is built up over multiple statements, not one line).

Doug
Top Expert 2016
Commented:
A better question might be - which uses more memory, StringBuilder or direct concatenation? If you use the latter and decompile the code, you will find the VM uses StringBuilder anyway, but, at least when i was last looking, not necessarily in an optimal way. Hint: look at the way SB grows in memory when used in a 'default' way
In terms of raw speed, you'd find that the variance between using concatenation or adding to a StringBuilder narrows significantly, and is effectively asymptotic. But you'd have to be dealing with a lot of strings, but it's worth bearing in mind.
Distinguished Expert 2019
Commented:
It doesn't matter, because the compiler will optimise the string concatenation and will use a StringBuilder internally anyway. But, philosophically speaking, StringBuilder is faster.
For a little historical context on this - in the early versions of Java, there was "StringBuffer".
So people wrote code using StringBuffer to create simple Strings.

But then StringBuilder was added in Java 1.5.  StringBuilder is faster than StringBuffer (no thread synchronization).
At that point, if you had code that was written using simple String concatenation, the compiler switched to using StringBuilder and your code got faster with no work on your part.  But if you wrote the code explicitly using StringBuffer, the compiler had to continue to use StringBuffer, so your code didn't get faster.

Hence why today we should use String concatenation for assembling Strings in a single line - it allows the compiler to "do what's best" and "what's best" can change over time as the compiler gets more optimized.

Doug
As a 'practical' observation, I ran a concatenation routine and a stringbuilder one on 570,000 strings. Each, and System.gc in between. The free memory at each stage was :

C:\EE_Q_CODE>java FileLines
Break . . .
stcmem is  1590467048 // free after the concat routine
bulmem is 1930915288 // free after builder

Author

Commented:
Hi krakatoa,

can you provide the sample example
for the above explanation
Well, I can't find the code I actually used, as I don't hang on to snippets for long, but you'd just need to declare a String and a StringBuilder, turn your List into an Array, and loop over an n-sized source of Strings for the two scenarios. I used the same source Strings for the concatenation and the StringBuilder, and between the loops, decluttered memory using System.gc() between the two scenario loops. Free memory can be obtained from

Runtime.getRuntime().freeMemory();

But as you can see from the results I posted already, there's a noticeable a difference in the free memory figures, but not a difference in terms of order of magnitude, so I can't see how you are going to be affected by much speed or memory concerns, unless you are dealing with monster numbers of Strings. Others may disagree.

Author

Commented:
thanks