Suggestion: optimize codegen for "simple" string interpolation

[jods4]

String interpolation simplicity and clearness makes it very attractive for formatting text.
In fact, at my company I've seen it used for things as trivial as var greeting = $"Hello {name}", which admittedly is only slightly nicer than "Hello " + name.

The thing is: it doesn't have the same performance characteristics. Currently C# converts an interpolated string into a string.Format("Hello {0}", name) call. This has the benefit of being the simplest implementation (from a compiler perspective). But it has quite some overhead: boxing of value type placeholders (such as numbers), parsing of the format string, validation of the parameters, etc.

Most of the time you may not care. But sometimes in hot path code you want to be very careful with those allocations and computations.

I suggest that the compiler could generate more optimized code in at least some (or all?) situations.

It is evident that when you convert to FormattableString or IFormattable you'd need to generate a specialized class for each template, which may be excessive (or not?).

In the common case of interpolating strings, you could turn the parameters into strings at interpolation site, with specialized code, so that value types don't require boxing.
Concatenation of the results could be done with string.Concat, which doesn't require allocating an array for up to 4 parts.

This means that code like string s = $"x: {x}, y: {y}", which is a common use of string interpolation, could generate the IL equivalent of string s = string.Concat("x: ", x.ToString(), ", y: ", y.ToString()) which is probably the most efficient code you could have to create that string.

If the compiler did that work, we would get both benefits of clean syntax and most efficient specialized code.

[alrz]

Related: #194.

[jods4]

Sorry about that, I did a search for issues about "interpolation", not sure how I missed this one.

Apparently the idea was dismissed, I will read why later on.

[jods4]

I read the other thread and @bbarry seemed to have made the argument that led to closing the issue.

I think not all arguments were convincing. Let me recap some of that thread objections.

First, keep in mind that we could choose to draw the line between what is optimized and what falls back to simpler codegen anywhere we want to. Most interpolations I see in code at work are basic: few parameters, no format, no alignment. Those could easily compile to specialized code.

(1) Thread #194 focuses on StringBuilder and dismissed string.Concat because "it allocates an array". Up to 4 string parts, string.Concat does not need an array.
For 5+ parts you need an array, it's true. Could be a compiler-generated thread-static string[] if you really wanted to but I don't think it's worth the complexity. It's about minimizing allocations, you can't bring them down to 0 for complex interpolations anyway.
Note that if you pool your StringBuffer, acquisition is not free and the final ToString() incurs an additional full result copy (because it's pooled).

(2) Alignment is perceived as a huge show stopper... Just add a helper method to align strings and we're done: RightAlign(x.ToString(format), 30).
This could be optimized further to avoid the additional intermediate string copy, if you really want to: var s = x.ToString(format); var pad = Pad(s.Length, 30); string.Concat("template ", pad, s, "template"). The pad helper could return predefined constants for small lengths.

(3) Boxing can't be removed most of the time. Argument is: when there's a format cast to IFormattable can't be avoided.
I think it could. 90% of the time, parameters of an interpolation either don't have a format or are of a value type. Now in the case of value types with a format: if they implement IFormattable publicly the compiler can take advantage of that. All BCL primitives do so, and most value types should, precisely because a public implementation avoids boxing. Changing a value type to add an explicit implementation of IFormattable when it previously was public would be a breaking change anyway.

I understand MS has finite resources and maybe there are more important problems..
In an ideal world, I see no technical reasons that common pieces of code can't be optimal, such as:

string s;
double x, y;
s = $"x: {x:N2}, y: {y:N2}";
// can become:
s = "x: " + x.ToString("N2") + ", y: " + y.ToString("N2");

string task;
Exception ex;
s = $"Failed {task} with error {ex.Message}";
// can become:
s = "Failed " + task + " with error " + ex.Message;

Such examples are very common and the generated code could be optimal.
If some people choose to write the longer version by hand because of perceived efficiency advantage, it's a fail 😢.

(Micro 😦) benchmark:
https://gist.github.com/mattwarren/d2be775eec5a7adba928

[gafter]

@jods4
$"{1}" is defined as a call to string.Format("{0}", 1). The spec for string.Format defines this as equivalent to string.Format(CultureInfo.CurrentCulture, "{0}", 1), which is defined as equivalent to

(CultureInfo.CurrentCulture as ICustomFormatter)?.Format(null, 1, CultureInfo.CurrentCulture) ?? (1 is IFormattable) ? (1 as IFormattable).ToString(CultureInfo.CurrentCulture) : 1.ToString()

Of course, since the compiler knows that 1 is of type int, which it can see implements IFormattable, it can simplify this to

(CultureInfo.CurrentCulture as ICustomFormatter)?.Format(null, 1, CultureInfo.CurrentCulture) ?? 1.ToString(CultureInfo.CurrentCulture)

Is that what you're hoping we'll do? I don't see how to get it any simpler than that.

Things are not much better for var greeting = $"Hello {name}":

var greeting = "Hello " + ((CultureInfo.CurrentCulture as ICustomFormatter)?.Format(null, name, CultureInfo.CurrentCulture) ?? name)

[jods4]

@gafter I was unaware that all formatting operations look whether CurrentCulture is a ICustomFormatter before doing anything else. At least I learned something, not sure I'll ever use it though ;)

This is indeed a roadblock for generating efficient formatting code.

Idea: given that almost all code runs with the built-in CultureInfo and those do not implement ICustomFormatter the compiler could generate a quick check and bail out to string.Format. Maybe the IL equivalent of:

string result = CultureInfo.CurrentCulture is ICustomFormatter ?
  string.Format("Hello {0}", name) :
  "Hello " + name;

I admit that it's getting complicated 😞
But perf-wise it would be optimal code most of the time, with just an additional typecheck.

[leppie]

@jods4 A good example is using the currency formatter.

[jods4]

@leppie can you elaborate? I'm curious and not sure what you refer to.

[leppie]

@jods4 $"{100.0:C2}". Dates, decimals also.

[jods4]

Oh sure. I use those all the time (numbers and dates mostly).
And they can convert to (100.0).ToString("C2").
This works because double implicitly implements IFormattable and this doesn't require boxing.

The feature I didn't know about was that string.Format and co. will first look at CultureInfo.CurrentCulture to see if it implements ICustomFormatter. And I checked on my machine, your usual locale does not.

[leppie]

It could take a fast path for string args though if it does not do that already.

[jods4]

@leppie
Amazingly @gafter wrote that according to the specs even strings without specified format have to go through ICustomFormatter if there is one.

I'm kind of wondering what a proper usage of that feature would be. I mean: if you want to override formatting for a class you don't have control of (so can't implement IFormattable), you can always pass your own IFormatProvider to the string.Format call. Creating your own CultureInfo to set an ambient override for all formatting calls may seem convenient but also very wrong at several levels.
Anyway, that's the specs so we have to live with it.

[leppie]

@jods4 is is pretty cheap check, so I guess it does not hurt much.

[leppie]

@jods4 Also such optimizations might even be performed by the JIT, or at least it could hint that way.