[Mono-devel-list] System.Reflection Performance

[Paolo Molaro]

On 01/06/04 Ben Maurer wrote:
> 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

Dude, you want me to tell you where the runtime is slow so that you can
complain about it? The last thing we need is people complaining about
issues we know already. It doesn't make sense.

At this time the mono performance issues we investigated and/or fixed
are broken down in very few categories (for real-world programs,
microbenchmarks can expose different ratios):

* (50%): the 'user' code is dumb, it uses slow algorithms (user code can
	be also the code in the base assemblies): this is the main
	performance culprit and any non-clr specific performance advice
	works here (that is: always measure and don't optimize the wrong
	things)

* (20%): the GC is slow: this is not all the fault of libgc, there are
	still some tricks we can use to speed it up (thread-local 
	multi-object alloc): we may need to see how libgc can be
	improved or how a different GC can be used (in either case the
	timeframe is mono 2.0). The only advice here is: try to allocate
	less memory and less objects (of course if you can measure a
	speedup after doing it).

* (15%): some managed/clr idioms or features lead to slower code than 
	necessary (foreach enumerators or heavy exception use are two
	examples): sometimes it's worth optimizing this kind of code,
	but sometimes it doesn't matter enough to uglify the code.
	It depends on a case-by-case basis: as always, measure it.

* (15%): the jit could do a better work optimizing the code. There are
	still a few major optimizations we haven't implemented in the
	jit yet but that the current design easily allows. Some of those
	will be implemented for mono 1.0. There are also a lot of small
	performance tricks we can do as well, as soon as someone has
	applications that need them and we have time to test and
	implement them.

For mono 1.0 we aim at changing the ratios to:
user: 65% (but significantly less in the mono assemblies)
gc: 15%
idioms: 10%
jit: 10%

and for mono 2.0, we'd have, hopefully:
user: 85%
gc: 5%
idioms: 5%
jit: 5%

Note as we reach for the ideal system, with 100% blame placed on the
user:-)
Anyway, the point to take home is: always measure, if you can't figure
out what's the issue, either look at the code (assemblies, runtime, IL, 
jit, in that order) or post a benchmark to the list and people will take
a look at it.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better