[Mono-devel-list] System.Reflection Performance

[Ben Maurer]

On Tue, 2004-01-06 at 12:50, Paolo Molaro wrote:
> > >       * 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 can substitute some method calls or property accesses with
> a small number of native instructions. Most people should just ignore
> this advice, because it's bound to lead to micro optimizations that turn
> out to hurt later on.

I can't agree with Paolo here more. If you are reading any of the advice
I am giving as `replace all instances of stra == "" with stra.Length ==
0,' then I am not getting across the message which I am trying to say.

Only in a place that is very intensive in string operations would you
ever make such an ugly change. I know Zoltan did have quite a bit of
success with this sort of change in the Tokenizer for MCS.

However, over the past month, MCS's improved speed has not come from
changes that can be made with sed. Two types of changes have been made,
high level, compiler specific behavorial changes and low level memory
allocation reductions. Though the first category has given us some
pretty bing wins, overall the second category has given the biggest
boost.


> Maybe the only good advice wrt performance is: use the profiler or
> otherwise time your application code and see the actual numbers

Again, cant agree more. I see many people go in with the mindset `lets
make this fast'. They collect no data and start guessing. And when this
happens, they usually find no success, most often the program gets
slower, the code uglier and the person does not notice. Dont do that
;-).

> of where the most time is spent and start optimizing the high-level code
> there (if it's not already fast enough) without uglyfying the code.
> If it's still too slow you might want to post to the list: it may well
> be you're hitting some part of the mono runtime that has not been
> optimized yet, or something that requires some jit help.

Again, i agree that we should be trying to do as much of this sort of
optimization as possible at the jit/runtime level. There, it pays off
for everyone.

However, I really think it would be great if the runtime people would
give us some help here. Even as a hacker, I have little to no idea where
the runtime is weak. Without this sort of information, it is hard to
pick out issues to complain about. What I think would really help is if
the runtime hackers could give a list of some of the known `weak spots,'
where the JIT/runtime could be doing more to optimize a specific type of
code but is not right now, that includes:

      * A short, simple description of the problem. Critical that a
        non-C programmer can understand basically what the problem is.
      * A description of the type of code that this would affect, I
        would love to see an example, but not necessary. In some cases,
        a statement like `if you see alot of calls to
        String::op_[In]equality, you might be checking for the empty
        string, in which case the runtime could do better'.

This would be a great help in spotting issues that we might want to
discuess on the lists.