[Mono-devel-list] Re: Dynamically changing classes?

Rodrigo B. de Oliveira rbo at acm.org
Thu Sep 25 10:17:02 EDT 2003

> Sure, InvokeMember() is bound to be slow (maybe we could see if we can
> speedup the mono implementation), but, for example, MethodInfo.Invoke()
> is a lot faster (it's currently 2-3 times slower than a ruby/perl method
> call and it could be optimized, probably). But those are not concept
> issues, just performance tuning issues.

How would the performance of MethodInfo.Invoke/Type.InvokeMember compare to
a dinamically generated
delegate stub?

I mean, instead of doing:

    obj.GetType().InvokeMember("member", ..., args);

The dynamic language implementation would do something along the lines:

    delegate object Function(object target, object[] args);

    object Invoke(object target, string member, object[] args)
        Type type = target.GetType()
        Function f = CheckFunctionCache(type, member, args);
        if (null == f)
            f = GenerateFunctionStub(type, member, args);
            UpdateFunctionCache(type, member, args, f);
        return f(target, args);

GenerateFunctionStub would dynamically generate something like the following
for a hypothetical doThis method taking a single int argument:

class Foo0001Stub
    object Foo_doThis(object target, object[] args)
        Foo foo = (Foo)target;
        return foo.doThis(Convert.ToInt32(args[0]));

After the first hit, the overhead is pretty much:
    * Function stub lookup in the cache
    * casting and converting the arguments (a smart compiler could get away
without Convert.ToXXX);



More information about the Mono-devel-list mailing list