[Mono-devel-list] System.Reflection Performance

Ben Maurer bmaurer at users.sourceforge.net
Fri Jan 2 12:02:11 EST 2004

On Fri, 2004-01-02 at 09:06, Paolo Molaro wrote:
> On 01/02/04 Ben Maurer wrote:
> > So, it is quite obvious that the GetType is the bulk of the problem.
> This was already discussed a few months ago. At the time I described how
> to fix the issue, but no enteprising mono developer showed up, so I
> committed my ten line patch today.
> Remoting should see a sensible speedup, too, since it uses GetType in
> places.
Paolo, your patch is absolutely wonderful. I cannot measure the
performance of the GetType operation with the loop count i used before,
it is under .2 seconds. That is a 100x improvement.

Great work.

> > I am wondering if any of the runtime gurus can think of ways to make
> > GetType faster. GetType is by no means *fast* in MS, it is not designed
> > to be. However, it seems reasonable that it should be a tad bit faster
> > than this.
> The current impl is probably as fast as it can be (with about 30 bytes
> of memory overhead per vtable: we'll see later if it makes sense to
> have a slightly slower implementation and to delay allocate the memory).
We are actually faster than MS now :). I agree, it wont get faster!

> > As a side note, I did a quick test on the Invoke call in MS.net, it is
> > pretty clear that they call the Binder iff the parameter type does not
> > match exactly (I tested by making a Binder that would always return 500,
> > and then called a method with the sig (int,int) with params (byte,int).
> > The first parameter was passed as 500, the second was unmodified.) So,
> > it appears we could change Invoke to do the check in C. In C we would be
> > able to take alot of shortcuts (not allocating the params array, quicker
> > type operations, etc, etc). I think this would be an easy way to fix the
> The Binder code needs some work to better match the MS implementation: I
> suggest not trying to optimize it until we actually cover all the
> corner cases and your suggestions can only be implemented in some
> special cases, anyway.

Well, my suggestion actually does not involve touching the Binder code.

What I am suggesting is that we check if the types match *exactly*
inside the runtime, and then we can call the binder *ONLY IF* it is not
an exact match.

As I said before, it seems MS does this. In fact, *not* doing it is
externally visable.

I realize it is a special case, but this special case happens to be the
most common case :).

-- Ben

More information about the Mono-devel-list mailing list