DP memory leak

4 views
Skip to first unread message

hammett

unread,
Dec 1, 2008, 6:29:03 PM12/1/08
to castle-pro...@googlegroups.com

Craig Neuwirt

unread,
Dec 2, 2008, 7:27:50 AM12/2/08
to castle-pro...@googlegroups.com
Didn't the Elutian guys report something like this.  I'll have to find the post

Fabian Schmied

unread,
Dec 2, 2008, 8:32:29 AM12/2/08
to castle-pro...@googlegroups.com
>> Can someone confirm/deny this?
>> http://forum.castleproject.org/viewtopic.php?t=4996

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

João Bragança

unread,
Dec 5, 2008, 4:52:37 PM12/5/08
to Castle Project Development List
I noticed something like this too in a different context, so I am not
sure if its related or it has been fixed since then. I use the WCF
facility with MonoRail. The facility wraps the WCF clients in a proxy
which are then injected into my controllers. When I updated to r5364
to get the component burden stuff I noticed that performance was
hampered considerably. When I rolled back to 5355 the problem went
away.

hammett

unread,
Dec 5, 2008, 5:59:13 PM12/5/08
to castle-pro...@googlegroups.com
Thanks for this feedback. It's probably the burden implementation that
is not optimized (yet).

Craig Neuwirt

unread,
Dec 5, 2008, 6:34:18 PM12/5/08
to castle-pro...@googlegroups.com
How do think the DP issue is related to component burden?

hammett

unread,
Dec 5, 2008, 7:18:44 PM12/5/08
to castle-pro...@googlegroups.com
Unrelated, that was my reply to Joao.

Craig Neuwirt

unread,
Dec 5, 2008, 7:24:19 PM12/5/08
to castle-pro...@googlegroups.com
Oh, ok.

Reply all
Reply to author
Forward
0 new messages