Is/can format strings benefit from interpolated string optimizations?

[iSazonov]

After #50601, #50635, #51962 we can

string message = string.Format(CultureInfo.CurrentCulture, "Current path: {0}", path);

convert to:

string message = string.Format(CultureInfo.CurrentCulture, $"Current path: {path}");

and my question is about follow common pattern:

string message = string.Format(CultureInfo.CurrentCulture, ResourceManager.GetString("Current_Path"), path);

where ResourceManager returns a localized version of "Current path: {0}".

Since ResourceManager returns the same string (until we change current culture that is very rarely) we could parse the format string once and cache/compile. Also in compile time we know all about argument and their types and I guess we could do the same optimizations as for interpolated strings.

In PowerShell we have a lot of such patterns with format strings from resources and only a few ones as static (which could be converted to interpolated string already today) and the optimization I ask could be very useful.

(I found similar dotnet/csharplang#2347 but that discussion was in another context.)

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

After #50601, #50635, #51962 we can

string message = string.Format(CultureInfo.CurrentCulture, "Current path: {0}", path);

convert to:

string message = string.Format(CultureInfo.CurrentCulture, $"Current path: {path}");

and my question is about follow common pattern:

string message = string.Format(CultureInfo.CurrentCulture, ResourceManager.GetString("Current_Path"), path);

where ResourceManager returns a localized version of "Current path: {0}".

Since ResourceManager returns the same string (until we change current culture that is very rarely) we could parse the format string once and cache/compile. Also in compile time we know all about argument and their types and I guess we could do the same optimizations as for interpolated strings.

In PowerShell we have a lot of such patterns with format strings from resources and only a few ones as static (which could be converted to interpolated string already today) and the optimization I ask could be very useful.

(I found similar dotnet/csharplang#2347 but that discussion was in another context.)

Author:	iSazonov
Assignees:	-
Labels:	area-System.Runtime, tenet-performance, untriaged
Milestone:	-

[stephentoub]

Duplicate of #50330

[iSazonov]

@stephentoub Thanks for pointing #50330. I think #50330 (as well as dotnet/csharplang#2347) discussion goes a little in a different direction. My reasoning comes from PowerShell.

PowerShell uses strong typed resources. This means that there is already a code generated at (before :-) ) compile time. But the code is still a wrapper around traditional resource strings.
Traditional resource strings are de-facto constants known at compile time. So we need to do next step and convert the resource strings to a code.
(Not all resource strings are an interpolated strings. So perhaps we need to explicitly annotate them as interpolated strings or/and put in new source resource file.)

Thus

string.Format(culture, FileSystemStrings.PathNotFound, path);

will be compiled to:

FileSystemStrings.PathNotFound(culture, path);

with (simplified) implementation:

class FileSystemStrings
{
    public PathNotFound(CultureInfo culture, string path)
    {
        string.Format(culture, $"Path not found: {path}.");
    }
}

Of course we need an analog of ResourceManager class to discover culture specific assembly, load it and cache result by culture as ResourceManager does.

I guess C# compiler could be so smart and does the work for us if FileSystemStrings.PathNotFound parameter would be annotated with new string interpolated attribute. At the same time to convert the resource file is probably better with a source generator.

This, of course, is not the final sentence, but just the initial considerations.