Limit impact of reflectable Invoke methods #83066
Conversation
We need delegate Invoke methods to be reflectable (see dotnet#70883), but sometimes we can avoid generating them (and if they're generic, also generating various native layout structures).
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsWe need delegate Invoke methods to be reflectable (see #70883), but sometimes we can avoid generating them (and if they're generic, also generating various native layout structures). Cc @dotnet/ilc-contrib
|
| bool isActuallyInvokable = !type.IsGenericDefinition; | ||
| if (isActuallyInvokable) | ||
| { | ||
| isActuallyInvokable &= !invokeMethod.Signature.ReturnType.IsByRefLike; |
There was a problem hiding this comment.
This won't work once #45152 is fixed. POR is to fix that in .NET 8 together with other reflection invoke related functionality and perf issues. cc @steveharter
There was a problem hiding this comment.
The good news is that the delegate I was after with this (something with a SpanAction) seems to have disappeared with the other PRs I did around #83069 so this is no longer needed. It would still be a size savings, not an interesting one.
This was only interesting because the SpanAction delegate happened to also have ValueTuple in the signature that calls default equality comparer and brings a ton of stuff into hello world.
We need delegate Invoke methods to be reflectable (see #70883), but sometimes we can avoid generating them (and if they're generic, also generating various native layout structures).
Cc @dotnet/ilc-contrib