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. On Wed, Sep 23, 2009 at 6:28 PM, Jonathon Rossi <[email protected]> wrote: > 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 > > On Thu, Sep 24, 2009 at 5:06 AM, jr76 <[email protected]> wrote: > >> >> 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. >> >> >> > > > -- > Jono > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
