On a large .NET Core-based solution I'm analyzing, about 2.7% of the heap (or 55Mb) is taken up by VisualStudioOptionsProcessor. The issue seems to be that the class holds on to a string that contains the entire command-line, which in the case of .NET Core projects can be extremely long due to all the framework reference parameters. This seems to be somewhat unnecessary as the only reason it appears we hold on to the string is so that if a ruleset file changes we can update the current diagnostic settings. It seems like we could simply remember only what diagnostic settings were specified on the command-line and use that to calculate the effective diagnostic settings instead when a ruleset file changes, without holding on to the entire string.
On a large .NET Core-based solution I'm analyzing, about 2.7% of the heap (or 55Mb) is taken up by VisualStudioOptionsProcessor. The issue seems to be that the class holds on to a string that contains the entire command-line, which in the case of .NET Core projects can be extremely long due to all the framework reference parameters. This seems to be somewhat unnecessary as the only reason it appears we hold on to the string is so that if a ruleset file changes we can update the current diagnostic settings. It seems like we could simply remember only what diagnostic settings were specified on the command-line and use that to calculate the effective diagnostic settings instead when a ruleset file changes, without holding on to the entire string.