Does .NET assembly size affect performance?

Question

Hi,

Does the size of a .net assembly affect performance at all?

How about the number of assemblies in your windows forms/web forms project?

Answer 1

One thing I know will affect performance, in relation to assembly size, at least if assembly size is related to number of classes, methods, etc.

If you use reflection and use a loop like for all assemblies, for all types in those assemblies, check if they have attributes, etc.. This might JIT static constructors and call these in some instances.

Ah, saw Jon's answer, forgot to mention. JIT'ing of code will only happen once per piece of code of course, so if all you do is reflect over the types, and never touch them afterwords, the size of the assembly will affect the duration of that reflection loop, but after that it shouldn't matter at all.

Answer 2

Well, each time an assembly is loaded there will be some hit due to the resolution penalty - finding the right file, potentially verifying the version number etc. This is likely to be primarily at start-up.

However, I don't believe it will affect "steady-state" performance significantly.

Answer 3

I highly doubt it affects performance to any measurable degree. There will be some penalty for loading it at startup; and the memory usage will probably be increased by a MB or two, but other than that - no. Well, unless you make code that suffers because of this yourself.

That said, I haven't seen any tests, so I might be wrong.

Answer 4

No , it does not affect

Answer 5

I have never encountered a significant hit to performance that I tracked down to either size or number of assemblies. The vast majority of significant performance problems I've tracked down have been the result of algorithmic weaknesses.

As Jon Skeet says, there will likely be some small hit due to resolution at startup. lassevk also has a point regarding the dynamic resolution of assemblies via reflection. Neither one of these should impact performance more than once over the course of the program, though, and in the normal course of things that probably isn't a significant performance hit unless you're working under some awfully strict perf constraints.

Perhaps some additional context as to the problem would be helpful. Are you asking this question because you have a piece of software with a lot of big assemblies and you're trying to speed it up, for example?

Answer 6

A compact framework DLL will always be loaded into a 64 kb minimum memory space, no matter how small it is. So, loading four separate 10 kb CF DLLs will cost you 256 kb on the device. If you combined them (ILMerge) it would only cost you 64 kb of memory on the device.

Answer 7

From Microsoft's Patterns & Practices Improving .NET Application Performance and Scalability Chapter 5:

Prefer Single Large Assemblies Rather Than Multiple Smaller Assemblies

To help reduce your application’s working set, you should prefer single larger assemblies rather than multiple smaller assemblies. If you have several assemblies that are always loaded together, you should combine them and create a single assembly.

The overhead associated with having multiple smaller assemblies can be attributed to the following:

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

Because you pay for only the memory pages your program accesses, larger assemblies provide the Native Image Generator utility (Ngen.exe) with a greater chance to optimize the native image it produces. Better layout of the image means that necessary data can be laid out more densely, which in turn means fewer overall pages are needed to do the job compared to the same code laid out in multiple assemblies.

Sometimes you cannot avoid splitting assemblies; for example, for versioning and deployment reasons. If you need to ship types separately, you may need separate assemblies.

Answer 8

I agree with Dan's answer and just to add a bit more info: here's another relevant blog post to support that point of view: http://blogs.msdn.com/junfeng/archive/2004/02/23/78139.aspx

Answer 9

Unused local variables and unnecessary assignments increase the size of an assembly and degrade performance.