The CLR employs a pay-for-play type model.

Here is what happens, more or less:

- You load the assembly
- At this point, you consume virtual address space. This is not the
same as physical memory. In most cases this is not a big deal,
particularly on 64-bit systems, like I'm using at the moment. But,
there is actually working set cost here. There is working set cost to
the mapping and to other OS mechanisms. And then the CLR creates a
bunch of data structures for that assembly. This is all before loading
any types. I don't have numbers or percentages handy, but loading isn't
free.
- You load a type
- Here you consume actual memory as we create data structures to
represent the type. The memory consumed here is only for that type and
isn't much -- no IL is loaded yet.
- You instantiate the type (run the class/instance constructor) or call
a method
- Here you consume memory again, as we load the IL for the method and
then JIT the IL, which leaves you with native code. So, here you have
IL and x86 instructions, which is two copies of your code in memory.
- The IL will eventually page away
- Even the jitted code will page away if no longer needed
- rinse and repeat for any other methods that you use on that type or
any other types you use within the assembly

So, you only load what you use. Also, there are some up front costs
that you have to pay for every assembly you load. In general, we advise
folks to generate fewer, larger assemblies.

HTH -- rich