Fewer smaller .Net DLLs vs less large DLLs

Generally speaking it is better to have less large DLLs versus many smaller DLLs for the following reasons:

Hard Disk time: Loading 100 dlls will almost always take longer than a single large DLL. DLLs are physically scattered across the disk. Latency etc come into play on the initial load times.
Memory Usage: A single dll contains 1 set of "standard" meta data vs 100 times that standard meta data can start to make up some memory space (i.e. X bytes of product name, version info, etc x 100 dlls x # of app domains = memory)
Security: .Net CLR has to do a lot more processing with multiple DLLs vs less DLLs. A security policy will need to be loaded, managed, and executed per each DLL.
CLR Management: If DLLs do not specifically call for a unique "base address" so the CLR must re-base each DLL when it loads them costing startup cycle time. Also when code executes the CLR must locate the object in memory and if it has to go through a "lookup table" of those addresses it will take longer to find one if multiple DLLs are used.
Management: Locating code, determining DLL references to use, build scripts, etc will take more time to manage in the SDLC.
Optimization: The .Net compiler can make more and better optimization decisions if acting on more code base. Smaller sets of code will provide less optimization opportunities.
Maintenance: Managing the additional project files, assembly info files, etc add time and understanding to developers.

Comments

Anonymous
December 28, 2009
ILMerge works great for this if you don't need dynamic loading of assemblies. I've found it doesn't work so well for plugins, PowerShell cmdlets, etc though due to interactions with other assemblies in the same appdomain.