String interpolation of only strings should light-up with string.Concat(params ReadOnlySpan<string>)

[stephentoub]

Currently string interpolation when all of the parts are strings prefers to lower to a string.Concat call when there's a string.Concat overload with the exact same number of string parameters. Beyond that, it falls back to using normal interpolation mechanisms. Now that in .NET 9 there's a string.Concat(params ReadOnlySpan<string>) overload, it'd be nice if string interpolation preferred to use that overload when it's available, when all the parts are strings, and when there isn't a better overload of string.Concat available. This statement is invalidated by the new params span overload, which can support passing in all of the strings without an allocation:

roslyn/src/Compilers/CSharp/Portable/Binder/Binder_InterpolatedString.cs

Lines 231 to 233 in 9177306

	// 4. The string is composed of more than 4 components that are all strings themselves. We can turn this into a single
	// call to string.Concat. We prefer the builder over this because the builder can use pooling to avoid new allocations, while this
	// call will need to allocate a param array.

cc: @333fred

[333fred]

@stephentoub do you want us to continue calling the discrete parameter versions for 4 or less strings, or just always use the params ROS version when available?

[stephentoub]

@stephentoub do you want us to continue calling the discrete parameter versions for 4 or less strings, or just always use the params ROS version when available?

Ideally it should use the discrete parameter versions when they exist, and fall back to the span overload when they don't. So, based on the APIs we have today, 1/2/3/4 strings will use the dedicated overloads and 5+ will use the ReadOnlySpan<string> overload. The span overload is just a bit more expensive as it needs to enumerate through the strings, whereas the dedicated overloads are all hardcoded to that exact number.

[stephentoub]

(Thanks!)

[stephentoub]

Also, and let me know if I should open a separate issue for this, currently if I do this:

string s1 = "abc";
string s2 = "def";
string s3 = "ghi";

string result = s1 + " " + s2 + " " + s3;

that compiles down to the equivalent of this:

string result = string.Concat(new string[] { s1, " ", s2, " ", s3 });

whereas it'd be nice if it instead compiled down to the equivalent of:

string result = string.Concat((ReadOnlySpan<string>)[s1, " ", s2, " ", s3]);

saving the string[] allocation and binding to the same overload we're talking about here for interpolation.

[333fred]

Hopefully I can address at the same time, let's just keep it in one issue.

[333fred]

Alright, so I did a bit of investigation yesterday, and talked with @AlekseyTs about some approaches, and there's a few things to address here:

• First, the interpolation and concatenation code is the same path for this, so addressing one will address both.
• There's some concern about metadata bloat. Let's say the user has 6 arguments in one function, 7 in another, 11 in yet another... each of these will need a discrete inline array type. This is potentially a lot of metadata bloat across a lot of assemblies, since practically every C# program is going to append strings in some manner. @stephentoub, is there any appetite for defining standard array types for, say, 1-20? Or some other number that we decide? cc @jaredpar
• What size should we tap out on and fall back to string array/defaultinterpolatedstringhandler? There are going to be files, particularly generated files, that append a lot of strings. How big of an inline array is too much of a risk to the stack?
• Similar to above, what about a single method that appends 6, 7, 8, and 9 length strings. Each of those will need a discrete inline array local, do we risk blowing the stack there too? Do we need to figure out some sort of pooling mechanism, and create array slices? Note that even if we do have a pooling mechanism, it is certainly possible to construct scenarios that will need to have all of those locals alive at the same time, such as (pretend that I have a lot more locals in each nested +) a + (b + (c + d).ToString()).ToString() + f.

Not sure whether solving these issues is going to fit in .NET 9 for us, @jaredpar can advise.

[jaredpar]

is there any appetite for defining standard array types for, say, 1-20? Or some other number that we decide

Brought this up when we initially did the InlineArray work. IIRC the conclusion was that for now we wouldn't add any new types to the runtime. However if we found the compiler generated types were hitting a threshold in user apps then we'd consider adding say 1-10 into System.Runtime.CompilerServices.

Now that Console.WriteLine effectively pushes more customer code towards using InlineArray it would be a good time to take a measurement and see if we want to react in net10.0.

Not sure whether solving these issues is going to fit in .NET 9 for us, @jaredpar can advise.

What is the risk / cost of the change?

[333fred]

At a guess, it's a week or two of work. Our lowering code here is pretty complicated, and depending on how intelligent we need to be about stack usage/pooling, there's going to be lots of dedicated testing to make sure we're not shipping regressions.

[stephentoub]

What size should we tap out on and fall back to string array/defaultinterpolatedstringhandler? There are going to be files, particularly generated files, that append a lot of strings. How big of an inline array is too much of a risk to the stack?

Is this different from collection expressions, where we decided to just always use inline arrays?