[browser][ST] trim ConcurrentDictionary

[pavelsavara]

For single-threaded Browser runtime

• in EncodingTable and TimeZoneInfo
• don't use ConcurrentDictionary and other items from System.Collections.Concurrent assembly in the CoreLib
  • so that we do not keep those types from trimming. Download size matters.
  • so that we don't have to spend CPU cycles on synchronization. We are mostly interpreting the IL.
  • previously we already did this for ConcurrentQueue in ThreadPoolWorkQueue
• this covers it with System.Runtime.Tests/TrimmingTests/DoesntIncludeConcurentTypes.cs
  • testing that we are trimming those types and whole assembly System.Collections.Concurrent
• make explicit dependency of System.ComponentModel.TypeDescriptor on ConcurrentDictionary in ILLink.Descriptors.LibraryBuild.xml
  • TypeDescriptor is already heavily marked with RequiresUnreferencedCodeAttribute

[dotnet-policy-service]

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

[jkotas]

Do you have any numbers for how much this saves for user apps?

ConcurrentDictionary is used pretty frequently for performance reasons. It is not practical to ifdef out every use of it. If we are not happy about its footprint for single threaded wasm, it may be better to provide an alternative lighter weight implementation instead of trying to ifdef out every use.

cc @stephentoub

[pavelsavara]

I admit that most normal applications would use those data structures.
On the other hand, some customers are very interested in pay for play size and I had to #ifdef only 2 places in corelib.

On the left is the same app with extra

        var x=new System.Collections.Concurrent.ConcurrentDictionary<int, int>();
        x[1] = 1;
        Console.WriteLine(x[1]);
        var y=new System.Collections.Concurrent.ConcurrentBag<int>();
        y.Add(1);

The difference is 46kb uncompressed.
Regarding perf I hope that R2R of just normal Dictionary would serve us better than to have 2 code bases.

Anyway, even if we revert most of this, I would like to keep non concurrent Queue in ThreadPoolWorkQueue and cover it with similar trimming test I drafted here.

[jkotas]

On the left is the same app with extra

I would like to see number for a Blazor app. (total size / bytes saved by this change)

I had to #ifdef only 2 places in corelib.

Ifdefs like this tend to keep growing to the point of being non-sustainable.

non concurrent Queue in ThreadPoolWorkQueue

That's fine with me. Queue is used a lot less frequently and ThreadPool has a bunch of ifdefs for single-threaded wasm, so one more does not sound like a problem.

[stephentoub]

I agree if there's a need for something like this, we should instead just have alternate impls of those data structures for the single threaded wasm use. Could be as simple as the public API shimming to a wrapped dictionary/queue.