Thanks
--
Cheers,
hammett
http://hammett.castleproject.org/
1 - An existing CLR and/or VS debugger bug leads to applications
generating lots of types into a single AssemblyBuilder getting slow
like hell _when run under the debugger_. There is no performance issue
without the debugger. The only way to remedy this (ATM) would be to
create separate AssemblyBuilders (for Castle that means separate
ProxyBuilder instances). AFAIR, in Rhino Mocks somebody implemented a
code generation cache (which would load/save the assemblies generated
by Rhino Mocks) to work around this problem.
2 - One AssemblyBuilder per proxy type is something I would most
strongly discourage. I myself have just finished a task cleaning up
our unit tests. Before the cleanup, every unit test would create its
own AssemblyBuilder, which lead to enormous native heap fragmentation
in the CLR, which lead to an enormous growth of the NUnit process
working set. (About 200 MB native memory leaked for about 1000 tests
involving code generation.)
3 - 5 GB memory for 100 proxy types (even with 50 members each) seems
enormous, I certainly have never seen such numbers.
Did you try it out?
Fabian