Perf trade off: lots of small assemblies or fewer bigger assemblies??

Over the internal CLR perf alias someone asked about what yields better performance having lots of small assemblies or a few of big ones… I thought I’d you’d find the comments from the team interesting...

As Rico would say, nothing is 100%, you have to measure, but the census of the CLR perf folks is that fewer bigger assemblies are better.

Lot of assemblies in the managed world is bad for the same reason lot of dlls are bad in the unmanaged world. The OS has a per-dll cost which is reduced by combining assemblies.  In addition, inlining can be more aggressive within an assembly

The biggest reason that assemblies are expensive is because we try very hard to make everything else ‘light’. Thus we try to push everything that can be shared to the assembly level that we can (thus it is shared among all classes in the assembly). Similarly, we try to optimize class loading at the expense of assembly loading, since we expect more class loads. If you have lots of small assemblies, you ruin this heuristic.

Assemblies are also the unit of enforcing security. Thus when doing cross assembly calls inlining is more constrained.

You are also fighting the OS heuristics. The File system is very good at prefetching data that is contiguous, however if you have lots of DLLs, they are not likely contiguous, which means disk moves, and significant loss of startup time.

Also, because of compatibility issues, changing assembly boundaries is painful. Thus it is worth some time ‘up front’ to insure that you can live with your present setup for a very long time.