Faster MethodInfo.Invoke

[davidfowl]

When writing a framework that dispatches to user methods it's quite common to reflect over all methods of a particular shape on an object and store a MethodInfo for later use. The scan and store is typically a one time cost (done up front) but the invocation of these methods happen lots of times (one or many times per http request for example). Historically, to make invocation fast, you would generate a DynamicMethod using reflection emit or generate a compiled expression tree to invoke the method instead of using methodInfo.Invoke. ASP.NET does this all the time, so much so that we now have a shared component to do this (as some of the code can be a bit tricky).

With the advent of newer runtimes like project N and coreRT, it would be great if there was first class support for creating a thunk to method. This is what I think it could look like:

class Program
{
 // First class delegate type in the CLR use to express the stub that calls into the
 // underlying method
 public delegate object Thunk(object target, object[] arguments);

 static void Main(string[] args)
 {
 var methods = typeof(Controller).GetMethods();
 var map = new Dictionary<string, Thunk>();
 foreach (var methodInfo in methods)
 {
 map[methodInfo.Name] = methodInfo.CreateThunk();
 }

 // Invoke the method index (result is null)
 var result = Invoke(map, typeof(Controller), "Index");

 // Result is 3 (yes things get boxed)
 result = Invoke(map, typeof(Controller), "Add", 1, 2);
 }

 private static object Invoke(Dictionary<string, Thunk> map, Type type, string method, params object[] arguments)
 {
 var target = Activator.CreateInstance(type);
 return map[method](target, arguments);
 }
}

public class Controller
{
 public void Index()
 {

 }

 public int Add(int a, int b)
 {
 return a + b;
 }
}

Few notes:

• We could disable type checking in the stub, if the caller passes the wrong arguments they would get an invalid cast exception.
• The arguments and return values are always boxed (that's not a huge deal for our use cases at least).

[jkotas]

You are really just asking for faster MethodInfo.Invoke - to make it precompiled, not interpreted. It does not need a new API. This performance improvement can be done without introducing a new APIs.

[davidfowl]

Sounds good. That would solve world hunger. Can you elaborate on why methodinfo.Invoke is slow today? What's the difference between Delegate.CreateDelegate() -> delegate.Invoke vs methodInfo.Invoke?

[jkotas]

MethodInfo.Invoke has to marshal the argument values from the boxed objects and put them into registers for the method to call. It is done via interpreter today. You can speed it up by precompiling the marshalling. It is essentially the same thing as what you are doing with expression trees today, except that it would be done in corelib using reflection.emit or something similar.

[davidfowl]

@jkotas Would it make sense to change the existing methodInfo.Invoke? Compatibility concerns etc?

You can speed it up by precompiling the marshalling

Is there any concern with storing the "precompiled" state?

I'd like to play around with this 😄

[jkotas]

Would it make sense to change the existing methodInfo.Invoke?

It does not make sense to introduce new APIs to fix perf issues in the existing APIs. Otherwise, we would end up over time with Invoke, InvokeFast, InvokeFaster, InvokeFastest, ... .

Compatibility concerns etc?

Yes, it takes extra care to ensure that you do not break anything.

Is there any concern with storing the "precompiled" state?

I did not mean to AOT compile, just compile it in memory on demand. It can be regular DynamicMethod.

You can take a look how it is done in CoreRT: https://github.com/dotnet/corert/blob/master/src/Common/src/TypeSystem/IL/Stubs/DynamicInvokeMethodThunk.cs

[davidfowl]

I did not mean to AOT compile, just compile it in memory on demand. It can be regular DynamicMethod.

I wasn't talking about AOT compilation, I was just asking if storing a dynamic method or whatever the extra state was on the MethodInfo would be a problem.

You can take a look how it is done in CoreRT: https://github.com/dotnet/corert/blob/master/src/Common/src/TypeSystem/IL/Stubs/DynamicInvokeMethodThunk.cs

Thanks! Now I just need to grok it and turn it into C++.

BTW are you suggesting we generate a dynamic method (via whatever mechanism is available) when creating method infos or would be a first time you invoke thing? (probably the latter)

[mattwarren]

What's the difference between Delegate.CreateDelegate() -> delegate.Invoke vs methodInfo.Invoke?

<shameless plug> This intrigued me as well, so I wrote a few blog posts about it, see Why is reflection slow? (section 'How does Reflection work?') also How do .NET delegates work? has some related info

I saw that MethodInfo Invoke also has to do security checks and parameter validation every time, which I guess adds to the cost

[jkotas]

Thanks! Now I just need to grok it and turn it into C++.

You do not need to. It can be in C# just fine.

[jkotas]

whatever the extra state was on the MethodInfo would be a problem

RuntimeMethodInfo has 12 fields already. Adding a 13th one should not be a problem; and if it is a problem - some of the existing 12 fields can be folded together.

[mattwarren]

Would this be something that is opt-in or the default behaviour?

There may be some scenarios where the extra overhead of time needed to create the delegate and then space to store it, could outweigh the cost of just using methodInfo.Invoke()

[mattwarren]

Also something similar was asked before, see #6968

[jkotas]

Right, it would need to be done only once the runtime sees the method invoked multiple times to be beneficial.

[davidfowl]

There may be some scenarios where the extra overhead of time needed to create the delegate and then space to store it, could outweigh the cost of just using methodInfo.Invoke()

Thats why I prefer the 2 stage approach, getting the method info then preparing it to get something back that is optimized for invocation. You pay that cost explicitly and up front. It also gets around any compatibility concerns around methodinfo.invoke.

Right, it would need to be done only once the runtime sees the method invoked multiple times to be beneficial.

We do something similar in our dependency injection system. After 2 invocations, we fire off a background thread for compilation so the next time it's faster.

[jkotas]

Thats why I prefer the 2 stage approach

Then this does not need to be built into the runtime. It can be regular upstack nuget package, e.g. the Thunk method can be extension method.