Comments on: Fast Late-Bound Invocation with Expression Trees

By: Tor Arvid Lund

Tor Arvid Lund — Thu, 19 Aug 2010 23:46:03 +0000

Ahh! Fantastic! This was just what I was looking for. After pulling my hair for hours, your little example helped me solve my issue in about 20 minutes.

Thanks a million!

By: Elegant Code » CreateDelegate<T> – An Exercise in Using Expressions

Fri, 30 Jul 2010 22:32:05 +0000

[...] going to outperform Delegate.CreateDelegate(). In fact, if you’re interested have a look at this approach first as it seems much faster. I added some spike code to the Elegant Code repository for those who [...]

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.