Do less work when resolving members of types

[MichalStrehovsky]

When constructing type system representation of a type member, we need two things - the token of the member, and type system representation of the owning type.

We have a couple places where we iterate members on a type - in those places, we already have a type system representation of the owning type. Shortcut the codepath that would recompute this information. This avoids finding the parent token of the token in metadata (this is an $O(log(N))$ operation) and the type system representation of the parent token (a hash table lookup, so $O(1)$ operation).

This kicks in quite often because a lot of EcmaMethods are materialized as part of virtual method resolution when we iterate all virtual methods on a type.

Cc @dotnet/ilc-contrib

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When constructing type system representation of a type member, we need two things - the token of the member, and type system representation of the owning type.

We have a couple places where we iterate members on a type - in those places, we already have a type system representation of the owning type. Shortcut the codepath that would recompute this information. This avoids finding the parent token of the token in metadata (this is an $O(log(N))$ operation) and the type system representation of the parent token (a hash table lookup, so $O(1)$ operation).

This kicks in quite often because a lot of EcmaMethods are materialized as part of virtual method resolution when we iterate all virtual methods on a type.

Cc @dotnet/ilc-contrib

Author:	MichalStrehovsky
Assignees:	MichalStrehovsky
Labels:	area-crossgen2-coreclr, area-NativeAOT-coreclr
Milestone:	-

[jkotas]

Nice!