| erik.scofield@gmail.com 2006-06-02, 7:06 pm |
| I created an encapsulation class for the codeDom some time ago to use
hear and there.
My objective was to hide from the user the very small details of
actually compiling the code and running it using very simple methods.
It also allows for compile once and run many by returning an identifier
to that created assembly. Now we are starting to actually use this
class in our ASP web application to allow for dynamic code
customization for all our clients.
Hear is the catch. I believe on average our clients my have 10 custom
codes pieces.. Each one is compiled individually. This means that for
every client I create 10 assemblies in memory. At 1000 clients this
could be a huge amount of assemblies.
Question:
Is 10000 tiny assembly any worse or better than forcing the code per
client to be generated into 1 assembly thus reducing the number of
assemblies to 1000 but increasing the Assembly size? So what are the
pro's and con's to having more smaller assemblies vs less larger ones?
I do not believe memory is the issue, how much overhead can an assembly
in memory really be? (and memory is cheap) The real question I wonder
is how much extra work is going on behind the scenes managing these
smaller assemblies? Or is this really not a concern as the assembly is
simply loaded into the heap and then reference VIA pointers anyhow?
Erik Scofield
|