[browser][ST] test trimming of System.Collections.Concurrent

[pavelsavara]

For single-threaded Browser runtime we already

• don't use ConcurrentQueue in ThreadPoolWorkQueue
• or any other items from System.Collections.Concurrent assembly in the CoreLib
  • so that we do not keep those types from trimming. Download size matters.
• this covers it with System.Runtime.Tests/TrimmingTests/DoesntIncludeConcurentTypes.cs
  • testing that we are trimming those types and whole assembly System.Collections.Concurrent

[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.

[pavelsavara]

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.

OK, I reverted the corelib changes and this is only trimming test now

[Copilot]

Pull request overview

This PR adds a trimming test to verify that System.Collections.Concurrent types are not included in trimmed single-threaded Browser runtime builds, reducing download size. The test validates that the CoreLib avoids dependencies on concurrent collections when threads are not enabled.

Changes:

• Adds a new trimming test that checks concurrent collection types are trimmed from Browser WASM builds
• Conditionally includes the test only for Browser targets without threading enabled

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
System.Runtime.TrimmingTests.proj	Adds conditional inclusion of the new test for single-threaded Browser targets
BrowserDoesNotIncludeConcurrentTypes.cs	New test file that verifies concurrent collection types are trimmed from the assembly

[pavelsavara]

[dotnet-policy-service]

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

[jkotas]

(Make sure that the commit description matches the final PR content when merging.)