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 force.com ?
string s = 'this'+'is'+'a'+'concatenation';
vs
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 ?
Attribution to: Samuel De Rycke
Possible Suggestion/Solution #1
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
Attribution to: techtrekker
Possible Suggestion/Solution #2
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'
Attribution to: Steven Herod
Possible Suggestion/Solution #3
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 Force.com) 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!
Attribution to: Andrew Fawcett
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/5215