• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

difference between operator + and concat in Strings ?

 
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Both are used to combine two strings ten what is the difference? Please explain me with an example ?
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Siva,
Take a look here
 
siva chaitanya
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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. :-)
 
Ranch Hand
Posts: 233
1
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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,
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 233
1
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Jeff! The news of compiler-specific implementation is new to me.
reply
    Bookmark Topic Watch Topic
  • New Topic