[Mono-devel-list] System.Reflection Performance

[Ben Maurer]

On Sat, 2004-01-03 at 05:45, David Sheldon wrote:
> On Fri, Jan 02, 2004 at 01:33:24PM -0500, Ben Maurer wrote:
> > So, in general the thing to follow is:
> > 
> >       * Check to see if the compiler is generating extra IL for you
> >         (like in the foreach case, where it makes two extra variables
> >         and adds in exception catching). Look at the IL it generates.
> 
> Is there an easy way to get the IL for a single method out of an
> assembly, or even out of mcs? I am also a little confused how to see
> what the JITer does with a method. Mono has --compile METHOD, but I
> spent some time working out how to specify the name of a method for it,
> and does it output anything unless you use -v -v? Is there a better way
> than doing this. I think that these might be the sort of things that
> should go in this document.

With monodis, no, sadly. If someone who knows C well would like to hack
this in (/me looks at Jackson, Lupus, Gonzalo, Miguel, Zoltan and
others) it would be a great hack :).

It would also be great if the runtime guys could explain how to get the
Assembly code from one method, and one method only.

> >       * Check if the JIT makes any of the items into instructions (such
> >         as String.Length).
> 
> Could you explain this one in more detail please?

The JIT turns some methods into inline code.
Examples include:
      * Math.{Sin, Cos, Tan}
      * String.Length
      * now, Object.GetType ().


> 
> > Lists like this are pretty silly, I do not keep one -- either in my head
> > or on paper. When I look at how to make mcs faster, I don't say:
> > 
> > `Man, today, why dont i replace all =="" calls with .Length == 0'
> > 
> > rather I say:
> > 
> > `Method Foo () runs REALLY slow, whats up with that'
> 
> Are you sure you don't keep one in your head, but a simpler one that
> says "Why on earth am I doing it this way, creating a whole bunch of
> objects when I could be doing it so much better"? Just knowing what
> creates a message bit of reflection and what is handled by the compiler
> will help people like me avoid doing really stupid things. 


Object allocation is not the only path to slow code.

Btw, Miguel and myself have started writing some performance guidelines.
The text is a bit rough right now. I would appreciate suggestions. I
would love if people would give us a list of `top 10 things i learned
about performance that are not obvious'.

-- Ben