Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I believe there is a performance benefit for using string format in languages like .NET and Java over concatenating strings. Is this also the case for Apex and ?

string s = 'this'+'is'+'a'+'concatenation';


string s  = string.format('{0}{1}{2}{3}',new string[]{'this','is','a','format'});

If there is no performance benefit, is there an encouraged best practice to use string format in cases where a concatenation would give the same result ?

share|improve this question
up vote 11 down vote accepted

As with Java, String's in Apex are immutable. Thus string concatenation results in a number of String instances (even for the literal strings) being created on the heap. As we know little about the internals of the Apex runtime (Java is much more open in this regard) its hard to say what impact this has on performance. Though it is a reasonable assumption it works the same way (as we know Java is used to build and thus you should give it at least the same considerations in my view.

As you and others have already pointed out String has a number of methods (format, join etc) that can be adopted and thus leave the internal optimisations upto Salesforce when they are. I would say the following are good best practice guideliens in my view.

  • Avoiding long concatenations. To much concatenation can be hard to maintain and thus raises the risk of bugs. So at the very least, breaking into multiple source lines, += lines and/or variables for clarity (though accepting some statement overhead for this). In general of course native methods such as the new String.join method. If things get complex (mix of literals and variables) and/or statements are concern, i like the use of String.format for things like dynamic SOQL as shown here.
  • Localisation. When bringing together messages presented to the end user I would always go for using String.format. Since it provides (if you later use Custom Labels) a means for translators to have greater flexibility to move the variable aspects of the message around, as some languages require.
  • StringBuilder. While doing effectively the same thing as above internally, if you need to pass around StringBuilder's (something I do miss at times in Apex), here is a good implementation with a few interesting subclasses.

Hope this helps!

share|improve this answer
Agree - String.format + Custom Labels for translatable end-user messages is the way to go – Stephen Willcock Dec 10 '12 at 12:02

I doubt there is a discernable difference to either approach. Perhaps there is a Salesforce engineer who could give deep insight in the benefits of one approach over the other.

From a readability POV I would say the first option using the '+' operator is more readable for simple cases, String.format() I'd use if I was assembling a more complex statement.

That said, any solution which requires a great deal of complex string concatination is probably a bad idea (I'm thinking people assembling JSON, XML or HTML documents by that mechanism). It's bad because its error prone, difficult to maintain, ignores standard functionality which performs the similar functions and expensive on your script statement numbers.

Finally I would also tend to capitalise 'String' to indicate its a class rather than 'string'

share|improve this answer

The String.Join native function that released in Winter 13 should have significant performance benefits over custom string concatenation. (If Strings are immutable like in Java, a new one is probably initialised each time the value of the variable changes)

List<String> tokens = new List<String>{'Hello', 'World'};
System.debug(String.join(tokens, ' '));

USER_DEBUG|[2]|DEBUG|Hello World

share|improve this answer
I would argue join is a convenience method and we have no idea if its actually any form of optimisation. SF should be abstracting away such low level performance items from us – Steven Herod Dec 11 '12 at 11:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.