Concatenating a lot of string objects ... string or stringBuilder

[Björn Björnsen]

Hi everyone,

I would like to discuss about how StringBuilder .append is better that String concatination + ?
It is clear that String is immutable, allits methods are doind well but when comed to concatinating alot of strings, we should avoid + and that iswhy StringBuilder is added. To build a string in a more efficient way.

String str= "ggg" + "hhh"+ ...

Stringbuilder strb = new StringBuilder().append("ggg").append(...

So, String calls concatination method and creates a new object for each and every + , because it is immutable.

That is why
String st = "hi";
String st1= st;
St == st1 is false, thay are pointing to diffrent refrence, diffrent memory address and a new obj is created.

But the same test with stringbuilder returns true. Because onle one obj will be created and since it is mutable. Since it is added to build a string in a better way...

Another important thing is, after each + , jvm calls garbage collection and  the previous obj will be garbage collected, so alot og GC will be performed also.

My question is, those reasons are clear to use stringBuilder when going to build a string with concatinating alot of literals.
Is there any other reason to use stringBuilder in that scenario?
And why still some people say use + and compiler will do amagic to create a bytecode like string builder!

But with that simple test, we can see the bytecode is diffrent and a new object will be created , sting is immutable and compiler cannotdo amagic to turn it to mutable. If even so, why stringBuiler even added and why by that name to emphesis use it when you build a string ?

Thanks in advanse for your reply and comment.

[Carey Brown]

Powerofviva Viva wrote:So, String calls concatination method and creates a new object for each and every + , because it is immutable.
That is why
String st = "hi";
String st1= st;
St == st1 is false, thay are pointing to diffrent refrence, diffrent memory address and a new obj is created.

That is incorrect,

		String st = "Hi";
		String st1 = st;
		System.out.println( st == st1 );

will return "true".

String s1 = "aaa" + "bbb" + variable1 + variable2;

The compiler will use StringBuilder to implement this so there's no advantage in you doing  it long hand.

String s2 = "Names: ";
for( int i = 0 ; i < 3 ; i++ )
    s2 = s2 + scanner.next();

Here compiler cannot automatically use StringBuilder and you'll need to write this long hand for best efficiency.

StringBuilder sb = new StringBuilder( "Names: " );
for( int i  = 0 ; i < 3 ; i++ )
    sb.append( scanner.next() );
String s2 = sb.toString();

[Campbell Ritchie]

Welcome to the Ranch

Powerofviva Viva wrote:. . . String str= "ggg" + "hhh"+ ...

Stringbuilder strb = new StringBuilder().append("ggg").append(...

The first code may be more efficient because any optimisation available will be used. In fact the concatenation will be applied at compile time because those two literals are compile time constants.
If you want a String you want a String. A StringBuilder

So, String calls concatination method and creates a new object for each and every + , because it is immutable.

No. the JLS = Java® Language Specification disagrees with you. Whatever method is called is an implementation detail and is expressly hidden in case it changes in more recent versions. Anyway, you only get problems with creating new String objects if you use + repeatedly in a loop.

That is why
String st = "hi";
String st1= st;
St == st1 is false . . .

Once we get rid of the spelling mistakes, the use of that == operator returns true.

But the same test with stringbuilder returns true. . . .

Does it?

those reasons are clear to use stringBuilder when going to build a string with concatinating alot of literals. . . .

No, you should use a StringBuilder for concatenating multiple Strings at runtime, nor literals

And why still some people say use + and compiler will do amagic to create a bytecode like string builder! . . .

Because it says in the JLS that,

That JLS page wrote:The String object is newly created (§12.5) unless the expression is a constant expression (§15.29).

…and in §15.29 it says that a String constant is automatically interned.

[Björn Björnsen]

,
My first post was incorrect.
I meant

String str = "hi";
String str2= "hi" + "";
str==str2 is false and the same concatination with stringbuilder is true .

After each + the previous string obj will be garbage collected right? (In runtime)

Moreover, if at the end, compiler will generate byte code to use stringbuilder, why do not use it from the beginning?

Also their bytecode is not 100% the same.

[Mike Simmons]

Powerofviva Viva wrote:So, String calls concatination method and creates a new object for each and every + , because it is immutable.

Well, no - not for each and every +.  For example:

String s = getFoo() + ", " + getBar() + ", " + getBaz();

The people who wrote the Java compiler are smart enough to realize they don't have to create four different strings here, just one.  They generate code that is equivalent to:

String s = new StringBuilder()
    .append(getFoo())
    .append(", ")
    .append(getBar())
    .append(", ")
    .append(getBaz())
    .toString();

Powerofviva Viva wrote:And why still some people say use + and compiler will do amagic to create a bytecode like string builder!

Ummm... because it's true?  But a key point  is to realize that saying it's like using StringBuilder is not the same as saying it's exactly the same.  Using a modern compiler you will probably see generated code that calls StringConcatFactory.makeConcatWithConstants() or something similar.  Which does a lot of surprisingly complicated things - but these do ultimately include making a StringBuilder to append all the arguments together.

Rather than worry about exactly what the bytecode does, however, I would suggest looking at two issues:

1)  Is a string make using + concatenation faster or slower than a string made with a StringBuilder?

2)  Is the code more readable, or less readable, than the code with a StringBuilder?

In many cases, the concatenation code is just as fast.  In some important exceptions, it is slower, sometimes much slower.  Carey's post shows an example of this.  In almost all cases, using concatenation is more readable - but, you need to pay attention to whether it's also creating a performance problem.

Powerofviva Viva wrote:Moreover, if at the end, compiler will generate byte code to use stringbuilder, why do not use it from the beginning?

Mostly because the StringBuilder code is usually more verbose.  It's not necessary.

[Campbell Ritchie]

Powerofviva Viva wrote:. . . After each + the previous string obj will be garbage collected right? (In runtime)

No. The concatenation in the code you showed will be done at compile time and there will be no objects to delete from memory.
It is possible that escape analysis will allow any objects created like that to be created on the stack and there will be no need for garbage collection.

Moreover, if at the end, compiler will generate byte code to use stringbuilder, why do not use it from the beginning?

Stop looking at implementation details which you don't need to know.
Because your attempt to optimise your code precludes further optimisation in future versions.
Let the runtime do its own optimisation; it is well‑recognised that people are not at all successful at optimising code, and frequently optimise what is already running fast and overlook the slower parts of the code.

Also their bytecode is not 100% the same.

Which bytecode isn't the same as what?

[Mike Simmons]

Campbell Ritchie wrote:Stop looking at implementation details which you don't need to know.

Well the thing is, this is actually rather close to an area where it is good for the programmer to know.  At least, past the beginner level.  Namely, the area Carey focused on in his first post, comparing something like

String s1 = "aaa" + "bbb" + variable1 + variable2;

with something like

String s2 = "Names: ";
for( int i = 0 ; i < 3 ; i++ )
    s2 = s2 + scanner.next();

I think it's good for a programmer to understand why using StringBuilder for the first code is unnecessary, but for the second, it's a very good idea, to avoid an O(N^2) performance issue.  So I would encourage questions in that area.  The problem is, it's hard for people to know where the boundary actually lies between that, and pointless worrying about the unimportant stuff.

My quick and dirty answer is: if you can build the String all in one line (possibly refactoring it into one very big line with a lot of +), then skip the StringBuilder step.  The compiler writer has already solved that for you.  But if the String needs to be build across multiple lines, and especially if it needs to be build inside a loop, but also accessed outside the loop - in that case, you probably want to use StringBuilder.

Campbell Ritchie wrote:Which bytecode isn't the same as what?

I believe he's referring to the fact that if you decompile the code generated from, say,

getFoo() + "," + getBar()

, it most likely is not the same as if you decompile the (presumably) equivalent

new StringBuilder().append(getFoo()).append(",").append(getBar()).toString()

In fact it looks quite different.  That's unfortunate, because it makes it look like these are very different things, when in fact, they are closely related.

[Björn Björnsen]

Thanks everyone for the replay, specially  Mike,
It is exactly a big string , about 50 concatenation and I agree with you, it is better to use StringBuilder compare to  + for such a long string to be on the safe side.

My last question is , since:

       

String str = "Hi";
         String str2 = str + "";
         System.out.println(str == str2);  // false

          StringBuilder strb = new StringBuilder().append("Hi");
           StringBuilder strb2 = strb.append("");
          System.out.println(strb == strb2);     //true

how many objects will be created in two examples below (lets say concatenating about 50 string literals) and how many times garbage collation will be performed?

String str = "AAAAAAAAAAAAAAAAAA1" + "AAAAAAAAAAAAAAAAAA2" + ... +  "AAAAAAAAAAAAAAAAAA50"

StringBuilder stringBuilder = new StringBuilder()
                    .append("AAAAAAAAAAAAAAAAAA1")
                    .append("AAAAAAAAAAAAAAAAAA2")
                     ...
                    .append("AAAAAAAAAAAAAAAAAA50");

[Campbell Ritchie]

Björn Björnsen wrote:Thanks everyone . . .

That's a pleasure

I agree with you, it is better to use StringBuilder . . .

And I disagree. You will not improve the performance by explicitly using a StringBuilder. You will get better performance with a StringBuilder only if the concatenation occurs in multiple statements, usually in a loop. It is worth using a StringBuilder if you are using a loop, or if you find its code easier to read.

My last question is , since:

       

String str = "Hi";
         String str2 = str + "";
         System.out.println(str == str2);  // false

          StringBuilder strb = new StringBuilder().append("Hi");
           StringBuilder strb2 = strb.append("");
          System.out.println(strb == strb2);     //true

Change line 1 to make the reference final and try again.
You are assigning an alias to the StringBuilder. Two identifiers, same object.

how many objects will be created in two examples below . . .

First statement, none. The concatenation is performed at compile time.
Second statement, one the StringBuilder.
All the other Strings are compile time constants and are created at class loading time.

and how many times garbage collation will be performed?  . . .

Probably never.

[Stephan van Hulst]

Björn Björnsen wrote:how many objects will be created in two examples below (lets say concatenating about 50 string literals) and how many times garbage collation will be performed?

If concatenating string literals or other compile-time constants of String type, then simply using the string concatenation operator will yield one string object per string literal, plus one string object for the concatenated result. Once the scope that holds the sole reference to the concatenated result ends, the concatenated result becomes eligible for garbage collection. Whether the garbage collector is actually run can NEVER be said with certainty. Objects resulting from string literals never become eligible for garbage collection.

In your example, concatenating 50 string literals using repeated calls to StringBuilder.append() will also yield one string object per string literal, plus one string builder object, plus a variable (but small) number of array objects contained within the string builder, depending on how often the inner array needs to be resized. Once the scope that holds the reference to the string builder ends, the string builder (and its internal array) become eligible for garbage collection. Any other arrays that were previously created become eligible any time the string builder resizes.

Using the string concatenation operator is usually more efficient when most of the concatenated strings are compile-time constants, such as string literals.

As has been pointed out by others, using StringBuilder directly only becomes efficient when you're concatenating many strings that are NOT compile-time constants, or when you're concatenating strings in separate expressions. An easy rule of thumb is whether you need a loop to create the string:

var stringBuilder = new StringBuilder();

for (var i = 1; i <= 50; i++) {
  stringBuilder.append("AAAAAAAAAAAAAAAAAA").append(i);
}

If you can create the string without using a loop or a recursive call, then you probably shouldn't worry about using a string builder, and instead just use the concatenation operator.

[Björn Björnsen]

Thanks Stephan,

But how, in the first example , the result of comparing two refrences from String == is false.
And the same for stringBuilder is true.

Isn't it that for concatinating two litrals with + a new string obj/refrence will be created so first result is false.

And for stringbuilder it will be only one obj for stringBuilder so the result is true?

[Stephan van Hulst]

In the first case, you're not concatenating two string literals. You're concatenating the value of a local variable with a string literal.

The result of string concatenation will only be an interned string value if the two string operands are compile-time constants. The local variable str is not a compile-time constant. Therefore, str+"" returns a reference to a new string object.

You can make either of the following two changes to make str == str2 evaluate to true:

final String str = "Hi";

OR

String str2 = "Hi" + "";

The reason that with StringBuilder it returns true, is that the append() method contains a small optimization. It does something similar to this:

public StringBuilder append(String str) {
  if ("".equals(str)) {
    return this;
  }

  // rest of the method implementation
}

The Java designers could have forced a similar optimization for the concatenation operator, but they chose not to. That doesn't mean that there are no Java implementations in which str+"" also gets optimized to just str.

[Campbell Ritchie]

Stephan van Hulst wrote:. . . The Java designers could have forced a similar optimization for the concatenation operator . . .

If they think it worthwhile, which it probably isn't, they might introduce such an optimisation into a future version. Of course, I haven't checked whether changing the semantics of + like that would be permissible.

[Carey Brown]

String str = "AAAAAAAAAAAAAAAAAA1" + "AAAAAAAAAAAAAAAAAA2" + ... +  "AAAAAAAAAAAAAAAAAA50"
 
StringBuilder stringBuilder = new StringBuilder()
             .append("AAAAAAAAAAAAAAAAAA1")
             .append("AAAAAAAAAAAAAAAAAA2")
             ...
             .append("AAAAAAAAAAAAAAAAAA50");

Even if you are concatenating 50 long strings you can do it with a (+) though your use of StringBuilder shouldn't really cost you any overhead.

String str = "AAAAAAAAAAAAAAAAAA1" +
             "AAAAAAAAAAAAAAAAAA2" +
             ...
             "AAAAAAAAAAAAAAAAAA50";

[Mike Simmons]

In general, for the question of whether an operation returns a new String or a reference to an existing String, that's really something that (a) people using the code shouldn't worry about, and (b) people writing the code (or compiler or JVM) often shouldn't even document.  That is, in Java you rarely want to use == to compare Strings anyway, and should avoid it when you don't really need it.  And from the perspective of the people maintaining Java libraries and tools, they may not be sure which optimizations are worthwhile and which are not - and they generally should try to avoid documenting specific implementation details as requirements, if they may later realize that there's a better way to do it.  Looking through the methods in the String class, for example, you can see that they've really been inconsistent on this issue.  The method join() specifically says it returns a new String, even though there are two cases, for length 0 and 1, where you really can use an existing string.  And trim() specifically says it returns the existing string, if no trimming is required.  But in both cases, the end user really has no reason to care, and the API writers should have just omitted that detail in case they ever find it necessary to change later.  In contrast, whether + creates a new String or not is unspecified (as long as it's not a constant expression)... and that is as it should be.  They may change their minds in the future if they find a reason to... and we don't need to worry about it.

[Mike Simmons]

Carey - well for a compile-time constant expression like that, there's really no reason to use StringBuilder at all.  But if you mean something that has non-constant parts as well, then yes they're pretty much equivalent.

Stephan van Hulst wrote:As has been pointed out by others, using StringBuilder directly only becomes efficient when you're concatenating many strings that are NOT compile-time constants, or when you're concatenating strings in separate expressions.

I (and Carey I think) would argue that it really only is useful when there are separate expressions.  You can have one really long expression with many non-constant parts, and as long as it's all one expression, concatenation with + will work just fine.  The string templates previewed in Java 21 also work pretty much the same way, equivalent to a long expression with many + but nicer formatting.

[Carey Brown]

String str = "AAAAAAAAAAAAAAAAAA1\n" +
             "AAAAAAAAAAAAAAAAAA2\n" +
             ...
             "AAAAAAAAAAAAAAAAAA50";

Note that combining lines of text ending with a new-line can be made more succinct using text blocks available in the latest versions of Java. See the triple quotes.

String str = """
             AAAAAAAAAAAAAAAAAA1
             AAAAAAAAAAAAAAAAAA2
             ...
             AAAAAAAAAAAAAAAAAA50""";

[Paul Clapham]

It may be relevant that a String object is more complicated than you might think. For example since Java 9 there is the concept of "Compact Strings". It used to be that a String contained an array of chars, but now if those chars can all be represented within a byte then the String contains an array of bytes instead. Presumably there's a flag to distinguish the two situations. This saves a lot of memory in programs with a lot of Strings in the English language.

Now, string concatenation has the possibility of concatenating an all-byte string with an all-chars string to produce an all-chars string. This seems straightforward to do. However StringBuilder doesn't have this optimization, it just has an internal array of chars. (Or anyway, I haven't heard otherwise. I'd be surprised if that was wrong.) So creating an all-bytes String out of a StringBuilder might have a performance issue. Although there's probably something the Java designers have done about that.

For more information see for example this tutorial: Compact Strings in Java 9.

[Mike Simmons]

It seems to me that for any StringBuilder or String concatenation expression where at least one part of the expression is not a constant expression, there's no way to know in advance if a particular String will be eligible for creation as a compact string.  You have to build the whole thing before you know if all the characters are Latin-1.  It looks like StringBuilder has a byte[] array, and starts with the assumption that it's going to see only Latin-1 characters, and so is using one byte per character.  But, as soon as it's asked to add something with a non-Latin-1 character, it recopies everything with UTF-16 and proceeds to use two bytes per char for the rest of its build.  Since non-constant String concatenation uses StringBuilder behind the scenes, it ends up using the same algorithm.  So, we're already getting the benefit of string compaction, regardless of the technique used.

[Campbell Ritchie]

Paul Clapham wrote:. . . It used to be that a String contained an array of chars , , , now if those chars can all be represented within a byte then the String contains an array of bytes instead. Presumably there's a flag . . . ..

There are two package‑private classes one for “Latin” Strings and one for other Strings. It is pretty easy to iterate a char[] to check that all its elements are < 0x80. It must be reasonably easy to interconvert the two types of array, otherwise it would have a serious performance himdicap.

[Mike Simmons]

Yeah, I was surprised they do it this way, because it does require recopying all the content of the array when they switch from one encoding to the other.  But that's also what StringBuilder does when it gets too big for a given backing array, same a ArrayList.  It's not a big performance hit as long as it doesn't happen too often.  For StringBuilder, we mostly hope that if it's a big string we're building, then if there is any non-Latin-1 content, it's nice to encounter it early on, when the cost of switching is small.  Because if you read one non-Latin-1 character at the very end, it forces a recopy of all the data in the StringBuilder so far.  But most of the time, if there is any non-Latin-1 content, then we see at least some of it early on.

[Campbell Ritchie]

Mike Simmons wrote:. . . if there is any non-Latin-1 content, it's nice to encounter it early on . . . .

In UK, we would say, “swings and roundabouts.”

[Björn Björnsen]

Here

String str = "Hi";
       String str2 = str + "";
       System.out.println(str == str2);  // false
       
Without adding final, it returns false.
Does it mean it creates a new obj for + if it is no final?
Can you please explain why is so?

[Campbell Ritchie]

Björn Björnsen wrote:. . . Does it mean it creates a new obj for + if it is no final?

If the compiler cannot determine that the two resultant Strings will have the same contents, then the concatenation will take place at runtime and different objects will be created. If you mark the variable in line 1 final, it becomes a compile‑time constant, officially called a constant expression. The JLS (=Java® Language Specification) will tell you all the gory details. Whether the variable in line 1 is final or not determines whether the expression to the right of the = in line 2 is or isn't a compile‑time constant. Whether they are or are not compile‑time constants determines when the String objects are created.

[Björn Björnsen]

But only making the first line final results true.
It means line 2  will be a compile time constant without any change in line 2.

     

  String str1 = "Hi";
        String str2 = str1 + "";
        System.out.println(str1 == str2); //false

   

   String str1 = "Hi";
         String str2 = str1 + "";
        System.out.println(str1 == str2.intern());  //true

 final  String str1 = "Hi";
        String str2 = str1 + "";
        System.out.println(str1 == str2); //true

for first one,+ creates another obj so == returns false

for the second one, it adds the value of str2 to string pool, so return true.

the third one, still is not clear to me, hmmm... by making the first line final, it will be compile time constant, and line 2 , even when it calls str1, still knows it is compile time constant and concatinate like two literals, so the result will be true?

the third one will turn to something like:

     

 String str1 = "Hi";
         String str2 = "Hi" + "";
        System.out.println(str1 == str2); //true

[Stephan van Hulst]

Björn Björnsen wrote:It means line 2  will be a compile time constant without any change in line 2.

No. A line can't be a compile-time constant. An expression can be a compile time-constant. In this case, the expression "str1" that is used in line 2 is a compile-time constant. And since the string literal "" is also a compile-time constant, the compiler can deduce that str1 + "" will ALWAYS be equal to "Hi", and simply reference the object in the string constant pool.

for the second one, it adds the value of str2 to string pool, so return true.

It doesn't. The value "Hi" is already in the string constant pool, because the string literal "Hi" was added to it when the class was loaded. This particular call to intern() simply finds the value that was already cached in the string constant pool and returns it. It doesn't actually add anything to the pool.

the third one, still is not clear to me, hmmm... by making the first line final, it will be compile time constant, and line 2 , even when it calls str1, still knows it is compile time constant and concatinate like two literals, so the result will be true?

Your understanding is correct, but your wording is wrong. The line isn't final. The variable str1 is.

But yes, you can imagine that making str1 final causes the compiler to inline its value as if you had used the literal directly in the string concatenation expression. That's not how the compiler REALLY works, but it's a good enough approximation for our understanding of this topic.

[Björn Björnsen]

This particular call to intern() simply finds the value that was already cached in the string constant pool and returns it. It doesn't actually add anything to the pool.

So you mean this particular .intern is redundant. But why without that .intern call, it returns false?
I mean as you mentioned, even with .intern we should get the same result, true, but it returns false.

[Stephan van Hulst]

Björn Björnsen wrote:So you mean this particular .intern is redundant.

That's not what I said. I said that this particular call doesn't add anything to the string constant pool. That's because a string with value "Hi" is already in the string constant pool.

The application prints true, because intern() returns that cached value from the string constant pool, but it doesn't add anything new to it.

[Björn Björnsen]

Yes, I got your point,
I am trying to summerize what I learned here, please correct me if I am wrong:

String str1 = "Hi";
		String str2 = str1 ;
		System.out.println(str1 == str2);  //true

 The code above is true because both sides are the same references.

as soon as it is being concatenated with empty string "" by using + :

       

String str1 = "Hi";
		String str2 = str1 + "";
		System.out.println(str1 == str2);  //false

it returns false because in code snipped above, str1 is in string pool, str2 is changes (is not the same as the first example ) and returns false.
             
so concatenating with + does something here on str2  (I mean the changed happened in str2) and str1 == str2.intern() make it true and it is logical.
the other solution, by making str1 final, compiler understand in line 2 that a call to local variable str1 is a call to a compile time constant and for the same reason, it returns true.

Is my understanding correct

[Stephan van Hulst]

Björn Björnsen wrote:so concatenating with + does something here on str2

Again, your understanding is correct, but your wording is wrong.

No. Using the + operator has no effect on str2. At runtime, the + operator just returns a new String object. It's the = operator that affects str2 by assigning a reference to the new string to it.

by making str1 final, compiler understand in line 2 that a call to local variable str1 is a call to a compile time constant and for the same reason, it returns true.

Yes, but note that this happens because the compiler does something that is similar to completely replacing

String str2 = str1 + "";

with

String str2 = "Hi";

The compiled code should no longer contain a concatenation operation.