Slow build and uses 16GB of RAM with a large file and nullable enabled

[meziantou]

Version Used: '4.12.0-3.24570.6 (913fb4e)'. Language version: 13.0.

Steps to Reproduce:

The repro has one large generated file (~160k lines) with #nullable enable at the top. Most lines add an entry in a ConcurrentDictionary.

1. git clone https://github.com/meziantou/repro-roslyn-nullable-largefile
2. dotnet build

The problematic file is https://github.com/meziantou/repro-roslyn-nullable-largefile/blob/main/HstsDomainPolicyCollection.g.cs

Expected Behavior:
The application builds without using more than 16GB of RAM

Actual Behavior:

• On my ARM64 machine, the build takes about 40s and uses about 16GB of RAM.
• On GitHub CI, ubuntu-24.04, the build fails. I suspect the machine doesn't allow memory swapping and crash.
• On GitHub CI, windows-2022, it completes but it is very slow (> 10 minutes)
  • https://github.com/meziantou/repro-roslyn-nullable-largefile/actions/runs/12507256671

Notes:
Disabling nullables in the generated files seems to fix the issue. It builds on Linux and it's faster on Windows. Note that there is a significant difference between Windows (80s) and Linux (20s), but maybe it's related to GitHub runners.

• With nullable: https://github.com/meziantou/repro-roslyn-nullable-largefile/actions/runs/12507256671
• without nullable (#nullable disable): https://github.com/meziantou/repro-roslyn-nullable-largefile/actions/runs/12507199016

I wonder if there is something in Roslyn that could be improved or if I should update the code generator to use another pattern.

Note: This code was just a first experiment to create my project. My final code doesn't use this logic as it has multiple drawbacks (IDE is not usage, JIT takes too much time).

[Youssef1313]

A quick hack you could try is to split all these TryAdd calls into multiple methods and see if it improves performance. I'm not confident it will work, but I think it's worth trying.

[meziantou]

I made a quick test to split the 160k statements in multiple methods:

• 1 method: 40s
• 2 methods: 27s
• 4 methods: 17s
• 8 methods: 12s
• 16 methods: 10s
• 32 methods: 10s

I tested it on a machine with 10 cores. When using 32 methods, the RAM usage is also much lower than with 1 method (2GB vs 10GB).