Is there a noticeable performance difference between using string interpolation:
myString += $"{x:x2}";
vs String.Format()?
myString += String.Format("{0:x2}", x);
I am only asking because ReSharper is prompting the fix, and I have been fooled before.
Noticable is relative. However: string interpolation is turned into string.Format() at compile-time so they should end up with the same result.
There are subtle differences though: as we can tell from this question, string concatenation in the format specifier results in an additional string.Concat() call.
int is used). var a = "hello"; var b = $"{a} world"; compiles to string concatenation. var a = "hello"; var b = $"{a} world {1}"; compiles to string format.The answer is both yes and no. ReSharper is fooling you by not showing a third variant, which is also the most performant. The two listed variants produce equal IL code, but the following will indeed give a boost:
myString += $"{x.ToString("x2")}";
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Configs;
using BenchmarkDotNet.Diagnosers;
using BenchmarkDotNet.Diagnostics.Windows;
using BenchmarkDotNet.Running;
namespace StringFormatPerformanceTest
{
[Config(typeof(Config))]
public class StringTests
{
private class Config : ManualConfig
{
public Config() => AddDiagnoser(MemoryDiagnoser.Default, new EtwProfiler());
}
[Params(42, 1337)]
public int Data;
[Benchmark] public string Format() => string.Format("{0:x2}", Data);
[Benchmark] public string Interpolate() => $"{Data:x2}";
[Benchmark] public string InterpolateExplicit() => $"{Data.ToString("x2")}";
}
class Program
{
static void Main(string[] args)
{
var summary = BenchmarkRunner.Run<StringTests>();
}
}
}
| Method | Data | Mean | Gen 0 | Allocated |
|-------------------- |----- |----------:|-------:|----------:|
| Format | 42 | 118.03 ns | 0.0178 | 56 B |
| Interpolate | 42 | 118.36 ns | 0.0178 | 56 B |
| InterpolateExplicit | 42 | 37.01 ns | 0.0102 | 32 B |
| Format | 1337 | 117.46 ns | 0.0176 | 56 B |
| Interpolate | 1337 | 113.86 ns | 0.0178 | 56 B |
| InterpolateExplicit | 1337 | 38.73 ns | 0.0102 | 32 B |
Re-ran the test on .NET 6.0.9.41905, X64 RyuJIT AVX2.
| Method | Data | Mean | Gen0 | Allocated |
|-------------------- |----- |----------:|-------:|----------:|
| Format | 42 | 37.47 ns | 0.0089 | 56 B |
| Interpolate | 42 | 57.61 ns | 0.0050 | 32 B |
| InterpolateExplicit | 42 | 11.46 ns | 0.0051 | 32 B |
| Format | 1337 | 39.49 ns | 0.0089 | 56 B |
| Interpolate | 1337 | 59.98 ns | 0.0050 | 32 B |
| InterpolateExplicit | 1337 | 12.85 ns | 0.0051 | 32 B |
The InterpolateExplicit() method is faster since we now explicitly tell the compiler to use a string. No need to box the object to be formatted. Boxing is indeed very costly. Also note that NET 6 reduced both CPU and memory allocations - for all methods.
Re-ran the test on .NET 7.0.122.56804, X64 RyuJIT AVX2.
| Method | Data | Mean | Gen0 | Allocated |
|-------------------- |----- |----------:|-------:|----------:|
| Format | 42 | 41.04 ns | 0.0089 | 56 B |
| Interpolate | 42 | 65.82 ns | 0.0050 | 32 B |
| InterpolateExplicit | 42 | 12.19 ns | 0.0051 | 32 B |
| Format | 1337 | 41.02 ns | 0.0089 | 56 B |
| Interpolate | 1337 | 59.61 ns | 0.0050 | 32 B |
| InterpolateExplicit | 1337 | 13.28 ns | 0.0051 | 32 B |
No significant changes since .NET 6.
Re-ran the test on .NET 10.0.0 (10.0.0-rc.2.25502.107, 10.0.25.50307), X64 RyuJIT x86-64-v3.
| Method | Data | Mean | Gen0 | Allocated |
|-------------------- |----- |----------:|-------:|----------:|
| Format | 42 | 23.517 ns | 0.0030 | 56 B |
| Interpolate | 42 | 20.666 ns | 0.0017 | 32 B |
| InterpolateExplicit | 42 | 6.195 ns | 0.0017 | 32 B |
| Format | 1337 | 24.496 ns | 0.0030 | 56 B |
| Interpolate | 1337 | 21.176 ns | 0.0017 | 32 B |
| InterpolateExplicit | 1337 | 7.095 ns | 0.0017 | 32 B |
No significant changes since .NET 7. We can conclude a few things:
string.Format() implies boxing of value types. (Verified with ildasm)ildasm)ToString() yields a tiny, tiny performance gain.
x is null, though.
myString += x.ToString("x2");?
"foobar" in your tests. Interesting... $"foobar{Data?.ToString()}" is compiled to string.Concat("foobar", Data.ToString("x2"))You should note that there have been significant optimizations on String Interpolation in C#10 and .NET 6 - String Interpolation in C# 10 and .NET 6.
I've been migrating all of my usage of not only string formatting, but also my usage of string concatenation, to use String Interpolation.
I'd be just as concerned, if not more, with memory allocation differences between the different methods. I've found that String Interpolation almost always wins for both speed and memory allocation when working with a smallish number of strings. If you have an undetermined (not known at design-time) number of strings, you should always use System.Text.StringBuilder.Append(xxx) or System.Text.StringBuilder.AppendFormat(xxx)
Also, I'd callout your usage of += for string concatenation. Be very careful and only do so for a small number of small strings.
The question was about performance, however the title just says "vs", so I feel like having to add a few more points, some of them are opinionated though.
Localization
string.Format. However, there is tooling for that (e.g. ReSharper).Maintainability (my opinion)
string.Format is far more readable, as it focuses on the sentence what I'd like to phrase, for example when constructing a nice and meaningful error message. Using the {N} placeholders give me more flexibility and it's easier to modify it later.string.Format is much less prone to this.So based on these, I decided to stick with string.Format in most of my code. However, I've prepared an extension method to have a more fluent way of coding which I like much more. The extension's implementation is a one-liner, and it looks simply like this in use.
var myErrorMessage = "Value must be less than {0:0.00} for field {1}".FormatWith(maximum, fieldName);
Interpolation is a great feature, don't get me wrong. But IMO, it shines the best in those languages which miss the string.Format-like feature, for example JavaScript.
{3} is X or Y especially if you start rearranging your format. Madlibs example: $"It was a {adjective} day in {month} when I {didSomething}" vs string.Format("It was a {0} day in {1} when I {2}", adjective, month, didSomething) --> $"I {didSomething} on a {adjective} {month} day" vs string.Format("I {2} on a {0} {1} day", adjective, month, didSomething)
string.Format I think you are much less prone to this issue. But anyway, this is why I emphasized that it's my opinion :)String interpolation is turned into string.Format() at compile-time.
Also, with string.Format(), you can specify several outputs for a single argument, and different output formats for single a argument.
But string interpolation is more readable, I guess. So, it's up to you.
a = string.Format("Due date is {0:M/d/yy} at {0:h:mm}", someComplexObject.someObject.someProperty);
b = $"Due date is {someComplexObject.someObject.someProperty:M/d/yy} at {someComplexObject.someObject.someProperty:h:mm}";
There are some performance test results available:
String::Format. and sometimes into String::Concat. And the performance-test on that page is imho not really meaningful: the amount of arguments you pass to each of those methods is dependent. concat is not always the fastest, stringbuilder is not always the slowest.Maybe too late to mention but didn't found others mentioned it: I noticed the += operator in your question. Looks like you are creating some hex output of something executing this operation in cycle.
Using concat on strings (+=), especially in cycles, may result in hardly discoverable problem: an OutOfMemoryException while analysing the dump will show tons of free memory inside!
What happens?
Note that the space allocated in step #1 is certainly bigger than the space freed in step #3.
In the next cycle the same happens and so on. How our memory will look like assuming 10 bytes long string was added in each cycle to an originally 20 bytes long string 3 times?
[20 bytes free]X1[30 bytes free]X2[40 bytes free]X2[50 bytes allocated]
(Because almost sure there are other commands using memory during the cycle I placed the Xn-s to demonstrate their memory allocations. These may be freed or still allocated, follow me.)
If at the next allocation MM founds no enough big continuous memory (60 bytes) then it tries to get it from OS or by restructuring free spaces in its outlet. The X1 and X2 will be moved somewhere (if possible) and a 20+30+40 continuous block become available. Time taking but available.
BUT if the block sizes reach 88kb (google for it why 88kb) they will be allocated on Large Object Heap. Free blocks here wont be compacted anymore.
So if your string += operation results are going past this size (e.g. you are building a CSV file or rendering something in memory this way), the above cycle will result in chunks of free memory of continuously growing sizes, the sum of them can be gigabytes, but your app will terminate with OOM because it won't be able to allocate a block of maybe as small as 1Mb because none of the chunks are big enough for it :)
Sorry for long explanation, but it happened some years ago and it was a hard lesson. I am fighting against inappropriate use of string concats since then.
There is an important note about String.Format() on Microsoft's site:
https://learn.microsoft.com/en-us/dotnet/api/system.string.format?view=net-6.0#remarks
Instead of calling the String.Format method or using composite format strings, you can use interpolated strings if your language supports them. An interpolated string is a string that contains interpolated expressions. Each interpolated expression is resolved with the expression's value and included in the result string when the string is assigned.
