proxy generation is slow when VS debugger is attached

[jr76]

Since moving to Dynamic Proxy 2, we have noticed that our application,
which uses NHibernate, runs *extremely* slowly when the VS debugger is
attached (calls that normally take about 1 second are taking up to 40
seconds to complete). Using dotTrace, we have tracked this down to
the System.Reflection.Emit.TypeBuilder.CreateType() method, which is
called by DP when it creates hibernate proxies. We never saw this
behaviour with DP 1.

Any ideas what might be causing this? Incidentally, it does not
happen when the debugger is attached through Task Manager - it only
happens when the debugger is launched or attached from VS.

[Jonathon Rossi]

Your issue sounds similar to:
http://support.castleproject.org/projects/DYNPROXY/issues/view/DYNPROXY-ISSUE-72

I am assuming it is caused by this BCL bug which we have no control over:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=472622

--
Jono

[Rob Redmond]

Just a followup to jr76's comments.

The BCL bug may not be the root cause;  the ticket on Microsoft Connect identifies the check for type naming conflicts as the source of the slow down.  The stack trace for the name check appears to be:

System.Reflection.Emit.AssemblyBuilderData.CheckNameConflict()

System.Reflection.Emit.TypeBuilder.Init()

System.Reflection.Emit.TypeBuilder.ctor()

System.Reflection.Emit.ModuleBuilder.DefineTypeNoLock()

Castle.DynamicProxy.Generators.Emitters.ClassEmitter.CreateTypeBuilder()

Castle.DynamicProxy.Generators.Emiitters.ClassEmitter.ctor()

Castle.DynamicProxy.Generators.ClassProxyGenerator.BuildClassEmitter()

Castle.DynamicProxy.Generators.ClassProxyGenerator.GenerateCode()

Our DotTrace investigation doesn't indicate that there is anything wrong during this construction of the ClassEmitter, so the type name conflict checking doesn't appear to have much of an impact.

All slowdown is observed further in ClassProxyGenerator.GenerateCode() when BuildType() is called on the ClassEmitter.  BuildType() ultimately makes a call to: System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()

CreateTypeNoLock is the method our trace is implicating as the hog.

Whether or not this is helpful remains to be seen :)  The microsoft connect ticket may have misidentified the cause to the defect, or perhaps DP is encountering a different defect (one that may not be so out of "our" control), or I may be placing too much faith in Reflector's ability to illuminate what's going on.  It at least hopefully warrants a little further investigation.

Rob.

[Krzysztof Koźmic]

Rob,

Can you send me your dotTrace file? I assume you profile with BCL profiling on, is that correct?

Krzysztof