Comments on: Fast Late-Bound Invocation with Expression Trees

By: Ameesh

Ameesh — Mon, 01 Mar 2010 18:43:37 +0000

Great work !

However while I can get this to work with most method calls, it doesnt seem to work with methods that dont have a return value. (void methods).. ?

By: AGS SOE’s without the SOAP – v2 « MapWrecker 2.0

AGS SOE’s without the SOAP – v2 « MapWrecker 2.0 — Thu, 14 Jan 2010 09:18:57 +0000

[...] however, is hardly the fastest way to dynamically invoke methods. Nate Kohari shows how to use LINQ expressions to create fast invokers for late-bound methods. Rick Strahl [...]

By: JP

JP — Sat, 20 Jun 2009 09:59:53 +0000

I think you’re idea is great. I’ve faced the same problem in the past and I completely missed the possibility of using lambda expressions.

Although I have no doubts that your solution works and is fast enough, I see some room for improvement.

First thing, you can add the ‘params’ keyword to the LateBoundMethod delegate like that:
public delegate object LateBoundMethod(object target, params object[] arguments);

With this, it’s not necessary to explicitly create an array when calling the delegate. For example, you could write:
bool result = (bool) callback(foo, “this”);
instead of:
bool result = (bool) callback(foo, new[] { “this” });

My second point is more relevant. I was worried about argument validation. For example, what would happen if someone calls a LateBoundMethod passing an incorrect number of parameters? Or if arguments = null?

Better than simply asking, I tested it. The asnwers were IndexOutOfRangeException and NullReferenceException, respectively. Both exceptions are somewhat ugly for a grownup component to throw. IMHO, the more “correct” exceptions would be TargetParameterCountException and ArgumentNullException.

I went ahead and tried to implement this change. I think I’ve reached a reasonable solution. Of course, argument validation will slow down the execution a bit for both generation and calling. Anyway, I believe any mature code should do this.

Nate, if you don’t mind, I’ll post my solution on my blog. Naturally, with a very big reference to the original author. In the meantime, if anyone is interested in seeing my code, send me an email (jpbochi at gmail dot com).

By: More on Late-Bound Invocations with Expression Trees - Jimmy Bogard -

More on Late-Bound Invocations with Expression Trees - Jimmy Bogard - — Thu, 18 Jun 2009 01:04:50 +0000

[...] it all looks quite ugly and hard to maintain. Until I stumbled upon Nate Kohari’s post on late-bound invocations via expression trees, I was avoiding that piece. The basic idea is that expression trees, when compiled, are able [...]

By: Nate Kohari

Nate Kohari — Wed, 11 Mar 2009 13:16:57 +0000

@Klaus: That’s true, with a language that supports dynamic dispatch, this would be simpler. However, the whole concept is to *reduce* the cost of late-bound invocation. Using Ruby, you pay a much higher price on *every* invocation, since the compiler can’t determine the method bindings at compile-time.

This isn’t to say Ruby isn’t a great language, but it’s also not the “next step” in programming — it’s just a different way of thinking that happens to have become more popular in recent years.

By: Klaus Hebsgaard

Klaus Hebsgaard — Wed, 11 Mar 2009 09:13:36 +0000

I remember when I coded C++ how memory management was a big issue, and I found it very exciting, and very nerdy.
In C++ people would do big (I mean BIG) work to make automatic memory management instead of running new() and delete() all the time.
And I remember thinking when I started coding C# that all this garbage collection was just for people who didn’t understand to code.
However I dit grow wiser and now understand how C# raised the bar (abstraction) for me so I didn’t have to do technically challenging and nerdy stuff, but simply use the right tool (.Net) for the right job.
I see the same thing here, what you are trying to do would be very easy and simple to do in a dynamic language like Ruby…

By: Rick Strahl

Rick Strahl — Tue, 10 Mar 2009 22:05:24 +0000

Nate – after running some perf tests on this I’m not sure if it’s worth it to do this, unless you make a boat load of calls against your dynamic delegate (and this might make good sense in nInject).

The compilation of the delegate is wickedly expensive – in my tests you’d have to make somewhere around 2500 Reflection calls to make up for the compilation overhead. Perf is super fast once you have the compiled delegate, but it’s heavy price to pay up front.

Here’s what I played with:
http://www.west-wind.com/weblog/posts/653034.aspx

By: Simone Busoli

Simone Busoli — Mon, 09 Mar 2009 17:26:00 +0000

I won’t go over your reply. Let me just say that you look like a skilled verbalist, and your replies to my comments were mostly out of context.
I know what you’re talking about, it’s just very badly exposed.

By: Nate Kohari

Nate Kohari — Mon, 09 Mar 2009 16:56:23 +0000

Here are my points:

1. Delegate.CreateDelegate() will create a new delegate at runtime, but to invoke it you have to use DynamicInvoke(), which is slow.

2. In order to avoid the cost of DynamicInvoke(), you have to call the Invoke() method on a delegate, which requires that you know (at compile time) the method’s signature.

3. The expression tree technique allows you to create a weak-typed open delegate, which casts the arguments passed in to the correct types, and invokes the original method.

4. You can call the Invoke() method of the delegate generated by the expression tree technique without knowing (at compile time) the types of arguments you’re passing in.

I don’t understand why you think that I’m incorrect, but I’m getting the impression that you either missed the point or that you just want to be argumentative. If it’s the former, I’ll ask you to re-read the original post; if it’s the latter, I’ll ask you to go elsewhere.

By: Simone Busoli

Simone Busoli — Mon, 09 Mar 2009 16:37:06 +0000

I don’t know either, you just keep saying the following

You still need to have objects of the proper types in order to pass them to the strong-typed Invoke() method of a delegate. The expression trees allow you to interface with the delegate with only a collection of weak-typed System.Objects

Which is wrong. What’s right, instead, is that the solution based on expressions is faster than other solutions.