Severe performance decrease when generating many types into an AssemblyBuilder - by xtoff_

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


27
0
Sign in
to vote
ID 472622 Comments
Status Closed Workarounds
Type Bug Repros 21
Opened 7/5/2009 1:46:55 AM
Access Restriction Public

Description

When creating a dynamic assembly (using System.Reflection.Emit.AssemblyBuilder) and creating multiple types in this assembly it has been observed that time to create a new type rises exponentially with the number of the types. Profiling showed that all the performance decrease is happening in System.Reflection.Emit.AssemblyBuilderData.CheckTypeNameConflict(string strTypeName, TypeBuilder enclosingType)

You can see this issue in Castle Dynamic Proxy issue tracker, and use attached program that exposes the issue:
http://support.castleproject.org/projects/DYNPROXY/issues/view/DYNPROXY-ISSUE-98
Sign in to post a comment.
Posted by Microsoft on 3/24/2010 at 10:11 AM
Hello,

I apologize for the confusion in the resolution state. As I mentioned earlier, we could not make this change to .NET 4 due to where we were (and are) in the product cycle - this item was actually fixed for the next version of the CLR (hence the resolution).

Again, sorry for the confusion.

Thank you,
Andrew
Posted by Firestrand on 3/24/2010 at 9:55 AM
This is still a problem in .NET 4.0 RC when I tested.
Posted by Microsoft on 7/14/2009 at 11:46 AM
Thank you for submitting your feedback to Microsoft. The current .NET implementation loops through all existing types to check for name conflicts when a new type is defined in a dynamic assembly. This makes the running time of creating a new type proportional to the number of types already defined in the dynamic assembly.

While this is certainly something we can look into improving, we likely won’t be able to address this in the .NET Framework 4 release, as the bar for bugs is extremely high due to where we are in the release cycle (close to Release Candidate). We will track this as something to investigate for a future .NET Framework release.

Thank you,
Andrew Dai
Microsoft Corp. – Common Language Runtime
Posted by Microsoft on 7/6/2009 at 1:45 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)