Dynamic static generic virtual method leftover work #80602
Labels
Milestone
Comments
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsSee the commented out tests in #80601.
|
MichalStrehovsky
added a commit
to MichalStrehovsky/runtime
that referenced
this issue
Feb 16, 2023
I'm looking at generic virtual method again because of dotnet#80602. The analysis of generic virtual methods within the compiler is an N * M algorithm where N is the number of unique generic virtual method instantiations called and M is the number of types that implement generic virtual methods. We use dynamic dependencies within the dependency analysis engine to model this relationship. It is important to try to limit the N and M. Looking at things, I realized the N we're currently operating on is bigger than it needs to be: ```csharp Foo f = new Bar(); f.Blah<int>(); f = new Baz(); f.Blah<double>(); class Foo { public virtual void Blah<T>() { } } class Bar : Foo { public override void Blah<T> { } } class Baz : Foo { public override void Blah<T> { } } ``` Previously, the analysis would see M = 3 and N = 6 because we would track each of the overrides as something that needs to be considered for each M. This changes the analysis to only look at the definition of the slot, i.e. N = 2 (one for int, other for double). The result of the analysis will still be same, it will just take less time. The new GenericVirtualMethodImpl node responds false to HasDynamicDependencies and doesn't participate in expensive activities.
MichalStrehovsky
added a commit
that referenced
this issue
Feb 27, 2023
* Split generic virtual method slot use and impl tracking I'm looking at generic virtual method again because of #80602. The analysis of generic virtual methods within the compiler is an N * M algorithm where N is the number of unique generic virtual method instantiations called and M is the number of types that implement generic virtual methods. We use dynamic dependencies within the dependency analysis engine to model this relationship. It is important to try to limit the N and M. Looking at things, I realized the N we're currently operating on is bigger than it needs to be: ```csharp Foo f = new Bar(); f.Blah<int>(); f = new Baz(); f.Blah<double>(); class Foo { public virtual void Blah<T>() { } } class Bar : Foo { public override void Blah<T> { } } class Baz : Foo { public override void Blah<T> { } } ``` Previously, the analysis would see M = 3 and N = 6 because we would track each of the overrides as something that needs to be considered for each M. This changes the analysis to only look at the definition of the slot, i.e. N = 2 (one for int, other for double). The result of the analysis will still be same, it will just take less time. The new GenericVirtualMethodImpl node responds false to HasDynamicDependencies and doesn't participate in expensive activities.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See the commented out tests in #80601.
The text was updated successfully, but these errors were encountered: