File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes difference between operator + and concat in Strings  ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "difference between operator + and concat in Strings  ?" Watch "difference between operator + and concat in Strings  ?" New topic
Author

difference between operator + and concat in Strings ?

siva chaitanya
Ranch Hand

Joined: Jul 05, 2011
Posts: 59
Both are used to combine two strings ten what is the difference? Please explain me with an example ?
changu mani
Ranch Hand

Joined: Aug 31, 2012
Posts: 30
Hi Siva,
Take a look here
siva chaitanya
Ranch Hand

Joined: Jul 05, 2011
Posts: 59
Thank you changu i came to know that by using + operator to combine two strings degrades the performance, the code below explains how much time taken to compile when we use concat and + operator in strings

Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

That performance test doesn't really prove anything.

Doing performance measurements, especially micro-benchmarks like this, is very hard in Java, because the JVM and the JIT contain very sophisticated optimization logic. For example, the JIT will translate your Java bytecode to native machine code, which runs much faster, but it doesn't do that immediately - it only does that when it notices some piece of code is executed frequently, so that it's worth the effort of translating it to native machine code.

It could very well be that the first loop in your program, lines 7 to 10, are not translated to native code because the JIT has not yet "warmed up", while it does translate the second loop to native code. There's no (easy) way to know exactly what the JIT does, but if it does these things, it can give you very misleading results for your little performance test.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37970
    
  22
Such performance tests should be run several times, at least 10×, and the order of the two operations being compared should be randomised. Even then it can give misleading information. If op1 takes 14 seconds on average and op2 16 seconds, that does not mean op1 is quicker; the difference is too small to mean anything. If op1 takes 14 seconds and op2 14 minutes on average, that probably does mean something. Also 10000 iterations is far to few; you should aim for 1000000×. And beware of the milliseconds method, which may not give sufficient precision to time your loops.

You are very unlikely to improve your performance by trying. What you learn from the old link is that writing s1 + s2 + s3 + s4 is fast, but using the + operator on Strings in multiple statements (or in a loop) is slow. I don’t think there have been any changes since that thread was written, and the String class quote didn’t change from Java6 to Java7.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7536
    
  18

siva chaitanya wrote:Thank you changu i came to know that by using + operator to combine two strings degrades the performance...

There's a wonderful old quote about optimization:
Michael A. Jackson wrote:RULES OF OPTIMIZATION
1. Don't do it.
2 (For experts only) Don't do it YET.
The fact is that neither you nor I know whether your above statement is true; and you should NEVER rely on anecdotal evidence when dealing with performance.

Furthermore, optimization is only worthwhile when:
(a) You know that your program is running too slowly (whatever that means).
(b) You can prove that it is a particular piece of code that is causing the problem.
(c) It DOESN'T adversely affect your design.

As for performance benchmarking, I generally use elapse time as my guide, rather than a number of iterations. I would regard any test that doesn't
(a) Average time over at least 100 iterations of the code in question.
(b) Run for at least 60 seconds, regardless of how many iterations that involves.
as suspect in the extreme. And for more complex benchmarks, you may need to run the code for an hour, a day, or even a week.

My 2ยข.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

I agree with Winston, what you should certainly not do from now on is always write .concat(...) every time instead of using + because you think that .concat(...) is faster.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

siva chaitanya wrote:Thank you changu i came to know that by using + operator to combine two strings degrades the performance,


That depends on what you're comparing it to. Using the + operator is never worse than using concat(), and in many cases is better.

This is always fine:



The compiler will turn it into as efficient a set of StringBuilder.append() calls and compile time constants as you could have yourself, but this way is easier to read than all the append()s.

Where you don't want to use + is like this:


In a loop like that, we create an unnecessary String object on each iteration. Better to use a StringBuilder and then call append() each time through the loop.

There should be no reason to ever use String's concat() method. (Now that I've said that, I'm sure one of the pedantic brainiacs here will come up with a reason.)

Having said all that, the point about premature optimization that others have made is valid. Even if you do it the wrong way, unless you're concat()ing HUGE strings, or a HUGE number of them, you'll never actually notice a performance difference. I'd still prefer the append() method when in a loop though, unless you're 100% sure it will never need to scale to where it could be a problem.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Jesper de Jong wrote:I agree with Winston, what you should certainly not do from now on is always write .concat(...) every time instead of using + because you think that .concat(...) is faster.


Yeah, that would be premature de-optimization. :-)
Rajdeep Biswas
Ranch Hand

Joined: Mar 26, 2012
Posts: 186

Jeff Verdegan wrote:

The compiler will turn it into as efficient a set of StringBuilder.append() calls and compile time constants as you could have yourself, but this way is easier to read than all the append()s.

Is that so? Is it JVM specific implementation?

P.S. I thought that the JVM searches for these literals in string pool, puts into pool if not already available, and then concatenates all, puts the concatenated string into the pool and returns the reference to it.

Regards,


The biggest gamble will be to ask a question whose answer you know in that it will challenge your theory | www.TechAspire.blogspot.in
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Rajdeep Biswas wrote:
Jeff Verdegan wrote:

The compiler will turn it into as efficient a set of StringBuilder.append() calls and compile time constants as you could have yourself, but this way is easier to read than all the append()s.

Is that so? Is it JVM specific implementation?


Yes, it is implementation-specific. And it's the compiler that does it, not the JVM. However, any modern, standard compiler will do that. There may be certain specialized ones that don't.


P.S. I thought that the JVM searches for these literals in string pool, puts into pool if not already available, and then concatenates all, puts the concatenated string into the pool and returns the reference to it.

Regards,


My example didn't have any particular literals. The a, b, c, etc. are meant to stand for any possible combination of literal, variable, method call, etc. I was speaking to the most general case.

However, if you have, for example:


then yes, the compiler will turn that into the single String literal "abcdef", which will get put into the .class file, and when the class is initialized at runtime, the JVM will create an entry to that String in the constant pool if it doesn't already exist, and any reference to "abc" + "def" or "abcdef" or "a" + "bc" + "d" + "ef", etc., will refer to that entry in the constant pool.
Rajdeep Biswas
Ranch Hand

Joined: Mar 26, 2012
Posts: 186

Thanks Jeff! The news of compiler-specific implementation is new to me.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: difference between operator + and concat in Strings ?
 
Similar Threads
difference between java Stream and Strings
HashMap ContainsKey() method asymptotic analysis
append AND concat
equals n ==
H&P