Remove allocations in ErorrFacts

[jaredpar]

When profiling our unit tests I discovered that ErrorFacts are a significant source of string allocations. In Emit for example it can be over 200MB of allocations.

This is due to our use of Enum.ToString as well as concat that value with well known constants. To avoid these allocations I changed our code generator to produce these strings at compile time.

I was a bit concerned about the performance of the switch compared to the existing code so I wrote a quick benchmark to demonstrate that there is no perf lost here.

Method	Runtime	Mean	Ratio	Gen0	Allocated	Alloc Ratio
EnumToString	.NET 8.0	66.80 us	1.00	-	45046 B	1.00
EnumToStringHelper	.NET 8.0	15.76 us	0.24	-	-	0.00
EnumToString	.NET Framework 4.7.2	512.30 us	7.69	21.4844	140197 B	3.11
EnumToStringHelper	.NET Framework 4.7.2	17.70 us	0.27	-	-	0.00

[jaredpar]

@dotnet/roslyn-compiler PTAL

[AlekseyTs]

emitOptions: EmitOptions.Default

What effect does this change have?

[jaredpar]

This is a different perf fix I was working on that I accidentally included with this change. I'll revert this part

[cston]

            case ErrorCode.ERR_NoMetadataFile: return "ERR_NoMetadataFile_Title";

Do we need a title string for errors?

---

Refers to: src/Compilers/CSharp/Portable/Generated/ErrorFacts.Generated.cs:2626 in cbcb2e5. [](commit_id = cbcb2e5, deletion_comment = False)

[cston]

            case ErrorCode.ERR_NoMetadataFile: return "ERR_NoMetadataFile_Description";

Do we need a description string for error codes other than warnings?

---

Refers to: src/Compilers/CSharp/Portable/Generated/ErrorFacts.Generated.cs:4509 in cbcb2e5. [](commit_id = cbcb2e5, deletion_comment = False)

[AlekseyTs]

    public static string ToStringWithDescription(ErrorCode code)

I am not sure what is the common pattern for using this API, but it looks like our resources contain only 20 ids like that and all of them are for warnings.

---

Refers to: src/Compilers/CSharp/Portable/Generated/ErrorFacts.Generated.cs:4157 in cbcb2e5. [](commit_id = cbcb2e5, deletion_comment = False)

[AlekseyTs]

    public static string ToStringWithTitle(ErrorCode code)

Similar to ToStringWithDescription, I think that only warnings have title ids in our resources.

---

Refers to: src/Compilers/CSharp/Portable/Generated/ErrorFacts.Generated.cs:2274 in cbcb2e5. [](commit_id = cbcb2e5, deletion_comment = False)

[AlekseyTs]

Do we understand why tests are requesting the strings? Would it be possible to decrease the allocation just by making changes to the test infrastructure?

[AlekseyTs]

If we go with the change, we probably should adjust the following comment at the end of ErrorCode.cs:

        // Note: you will need to do the following after adding errors:
        //  1) Update ErrorFacts.IsBuildOnlyDiagnostic (src/Compilers/CSharp/Portable/Errors/ErrorFacts.cs)

        // Note: you will need to do the following after adding warnings:
        //  1) Re-generate compiler code (eng\generate-compiler-code.cmd).
        //  2) Update ErrorFacts.IsBuildOnlyDiagnostic (src/Compilers/CSharp/Portable/Errors/ErrorFacts.cs)

[AlekseyTs]

I am not sure that we are optimizing for a common real-world scenario, but we are definitely paying with more memory usage by the compiler (string heap, code size, etc.) for all scenarios.

[jaredpar]

@AlekseyTs

Do we understand why tests are requesting the strings?

The primary method that causes issues is ErrorFacts.GetMessage. That is called indirectly in a lot of places in our test infrastructure. There are a few central places like DiagnosticsInfo.AssertExpectedMessageArgumentsLength but hard to change those to not realize the string in some way.

Would it be possible to decrease the allocation just by making changes to the test infrastructure?

The places I've dug into need to realize the string in some way to do their job.

I am not sure that we are optimizing for a common real-world scenario, but we are definitely paying with more memory usage by the compiler (string heap, code size, etc.) for all scenarios.

I agree that is a consideration we should make. The ErrorCode.ToString() path does seem to be both a real world and test concern. Creating diagnostics is common, and often loads of diagnostics, and today that has unnecessary allocations.

The WithTitle and WithDescription allocations are much smaller comparatively. There are a few test assemblies where those show up more prominently but overall they're not as critical to our test allocations as ErrorFacts.ToString. If we're concerned about expanding the string heap that much could definitely remove those.

[jaredpar]

I am not sure that we are optimizing for a common real-world scenario, but we are definitely paying with more memory usage by the compiler (string heap, code size, etc.) for all scenarios.

I dug into this a bit more and wrote a program to dump the UserString heap size and then did before / after comparisons.

Configuration	Size (bytes)
Existing Behavior	316,768
ToString generated	316,812
ToString, Description and Title Generated	585,432

Looking at that I agree that the price we're paying for ToStringWithTitle and ToStringWithDescription is too high and that should be backed out. The change to take ToString seems reasonable at a glance to me.