Performance of single assembly vs multiple assemblies

[alexandrehtrb]

There is an old MSDN article (2004) that teaches us that we should prefer a single assembly (DLL) over multiple assemblies, for reasons such as:

• The cost of loading metadata for smaller assemblies.
• Touching various memory pages in pre-compiled images in the CLR in order to load the assembly (if it is precompiled with Ngen.exe).
• JIT compile time.
• Security checks.

I wonder if this still holds true for current .NET.

Could dotnet publish condense multiple assemblies into a single one, through the use of a flag, for example?

Also on Stack Overflow

[jkotas]

Each assembly has fixed overhead. It is still the case that fewer bigger assemblies is better that more smaller ones.

The per-assembly fixed overhead is relatively significant for very small assemblies (<10kB). It is not a concern for bigger assemblies (>100kB).

Could dotnet publish condense multiple assemblies into a single one, through the use of a flag, for example?

Publishing as single file can avoid some of the overhead, but it cannot eliminate. The assembly boundaries are visible through reflection APIs, so they have to be kept in some form to avoid reflection API behavior changes.

[Suchiman]

There is no assembly loading in NativeAOT so yes that would help. ReadyToRun would not though.

[jkotas]

Does AOT compilation solve this?

The fixed per-assembly overhead is small with AOT, but it is not zero.

[alexandrehtrb]

Could we turn this into an issue?

This can be a performance improvement, as many .NET solutions I have seen are divided in small assemblies.

[jkotas]

What would the issue be about?

We do have PublishSingleFile and PublishAot options that create a single file that can be used to address some of the per-assembly overhead.

For advanced users, there are tools like https://github.com/gluck/il-repack. These tools can reduce the overhead even further, but they typically require non-trivial custom settings to make things work in specific situation.

many .NET solutions I have seen are divided in small assemblies.

Yes. Many .NET solutions like that load a fraction of the small assemblies during startup. Automatic merging of the small assemblies would be a regression for these solutions. Many small assemblies are fine if they are loaded lazily.