Remove FindTypeDef api where appropriate. #95297
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…class - Move namespace/name splitting to the Type.GetType code paths - Move exported type handling into the normal PopulateAvailableClass flow - Remove unnecessary work done to detect typedef name duplicates. We don't attempt to protect against invaild assemblies anymore - Unify path for insertion between ExportedType and TypeDef records, also unify the path for nested vs non-nested - Fix logic which implements inserts into the case insensitive table when dynamically adding entries to the ExportedType table (Previously it didn't work) - Update the ECMA 335 augments to capture the requirement that nested ExportedTypes must have a higher RID than the enclosing ExportedType - This requirement has actually always existed since .NET 1.0, but was never recorded
…is a linear scan of the entire typedef table, and we already have the right hash to make this cheap
- Also make the code more DAC correct (probably not completely correct, but this logic does not appear to actually be used within the DAC)
- Remove all uses in the runtime in favor of using the class hash - Port the existing code to be on top of the metadata api so that ildasm can continue to function
ghost
closed this
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
This pull request was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When loading a valuetype, which has a valuetype field referenced via a TypeRef, we use FindTypeDef on the metadata api to find a possible implementing TypeDef. This api is O(N) where N is the number of TypeDefs in the module. Coincidentally, the EEClassHashTable contains all of the data necessary to do this lookup. Use it instead, and see a substantial improvement in the performance of type loading valuetypes which have fields of valuetypes in other modules, when the valuetype is contained in a module with a large number of TypeDefs.
Additionally, there is a case where we do this as part of ExportedType handling. I've factored this change to include that fix as well, while I research whether or not that form of ExportedType is something we still need to support at all. (The logic was originally only needed for Multi-Module assemblies, and constructs which depend on this particular ExportedType behavior are not legal in ECMA 335 metadata, but that doesn't necessarily stop compilers from generating code which functions.)
Also, remove the FindTypeDef api from the metadata reader entirely. Now the only code which needs something like it is in ILDASM, so just re-implement it there.
This branch is additional work on top of #94825 which improves type load performance further in cases where we have many types in a single module.