[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);
Thoughts?
Rodrigo
More information about the Mono-devel-list
mailing list