..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] "Josh Buedel" <jbuedel@gatewayedi.nospamplease.com> wrote in message
news:%23V$v37pbEHA.644@tk2msftngp13.phx.gbl...
> 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
>
>