Groups | Blog | Home
all groups > dotnet clr > july 2004 >

dotnet clr : Code size effects on application performance


Josh Buedel
7/20/2004 4:17:26 PM
Hello,

I am searching for information on the performance impact/implications of
using large assemblies (>1MG).

Is an assembly loaded fully into memory? Or are the classes loaded as they
are needed? As far as execution time, you take a one time hit at
application load, correct? And even so, is it more than a few milliseconds?

In my situation, I have a library assembly that has grown to just over 1.7
MG. Even so, it is a logical placement for the classes it contains. Am I
paying for my code clarity with a performance penalty?

Thanks,
Josh

Daniel O'Connell [C# MVP]
7/21/2004 1:56:00 AM

[quoted text, click to view]

Actually, on the whole, a single large assembly will be slightly cheaper
*if* you are using most of that assembly. Now, if you have a situation where
only a portion of a given assembly will be used or other ways you can
partition the code, then by all means do so. Don't break your designs
unnaturally though, the performance is unliekly to be an issue

Anyway, there is a discussion on this issue here
http://blogs.msdn.com/brada/archive/2004/05/05/126934.aspx

Enjoy, ;).

Murat KARATUTLU
7/21/2004 9:35:33 AM
..NET runtime uses a technology called JIT (Just In Time) compilation...
the whole assembly is not loaded into the memory in order to be executed (or
called)
but as the methods receive calls, they are compiled and cached for further
calls. (see. JITter or JIT Compiler)

Of course using very large assemblies is not recommended (i dont think i've
seen more than a few libraries larger than a few hundreds of KB)
the impact of the size over the performance would not be as much as you
think.

nevertheless i recommend you to split the assembly into a few assemblies
grouped by their functionality.

But just take yourself as the runtime engine, you will load a type from an
assembly into the memory, would not it be easier to search for a specific
type in a smaller assembly, since there is a smaller space to look for...

and another option may be bypassing the JIT compile mechanism. instead of
copiling and caching you may use the ngen.exe tool to generate a native
(pre-compiled) image of the assembly and cache it on the system.

at this point you may wish to visit the URL
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfNativeImageGeneratorNgenexe.asp

Murat



[quoted text, click to view]

AddThis Social Bookmark Button