Add APIs to clear static caches

[cdmihai]

MSBuild API users doing a large number of evaluations / builds might need to do other non-msbuild related expensive work after they're done with msbuild. However, since MSBuild has a bunch of static caches (e.g. OpportunisticIntern) there's no easy way to clear these. Some users clear them via reflection. We could add static methods to ProjectCollection and BuildManager to clear these.

[4creators]

Related issue for MSBuild project builds which could be addressed as well: https://github.com/dotnet/coreclr/issues/16362, #2993.

Recent CoreCLR PR is a workaround for MSBuild ConfigCache problems with huuuge impact on build performance: dotnet/coreclr#17161

Build time improvement is ~326% what translates into build time reduction from 165 minutes to 38 minutes !!!

[rainersigwald]

@4creators that is not related. Clearing static caches would only help when running individual, disconnected builds, which is not the case for coreclr tests.

[danmoseley]

Of course, some caching also has observable behavioral effects, eg., IIRC the ProjectRootElement cache also deduplicates them, which is important if you're editing. It would need to be dealt with carefully.

[rokonec]

@cdmihai Is this still considered an issue after 2 years, or shall we close it?

[cdmihai]

Close the issue for now, and we'll reopen it if / when we notice this issue again. This will also become less of an issue for QuickBuild because it is moving msbuild project evaluation out of proc.

@ladipro QB has this code snipped that uses reflection to clear the opportunistic intern caches https://dev.azure.com/mseng/Domino/_git/CloudBuild?path=%2Fprivate%2FBuildEngine%2FEnlistment.Library%2Fsrc%2FTraversal.cs&version=GBmaster&line=616&lineEnd=652&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents
Is this still an issue after your rewrite of the string cache? Can your version get cleared more easily, or should QB just update its reflection code?

[ladipro]

@cdmihai the new cache will empty itself automatically when the process starts doing other things and the strings are no longer rooted. It would probably still be faster to remove everything in one go using code like this:

WeakStringCacheInterner.Instance.Dispose();
WeakStringCacheInterner.Instance = new WeakStringCacheInterner();

But I'd suggest to measure first to make sure that it's worth it. The type is internal so it would have to be done through reflection.