[Mono-list] mono performance on highly recursive functions

[Paolo Molaro]

On 02/17/03 Fergus Henderson wrote:
> There are lots of other optimizations which can be done at the IL->IL
> level, many of which *do* require lots of processing time.  To avoid
> duplicating these optimizations in multiple language front-ends, it makes
> sense to have an IL->IL optimization tool.  Then you can do it once
> in the IL->IL optimization tool, at zero run-time cost, rather than doing
> it in the JIT at a small but non-zero cost in time and working set size
> (due to the code for detecting when this optimization can be applied)
> at run-time.

If you're willing to do the preprocessing, you can just use an ahead of
time compiler: that will reduce the jit processing time much more than
optimizing just the IL code. There are also several reports at least by
the MS people on how trying to outsmart the JIT by optimizing the IL
code may result in the JIT missing some optimization opportunities.
And I can understand that, a tool working on the IL code doesn't have
all the info the JIT has.
Anyway, even if you write an IL optimizer, the optimizations need to be
implemented in the JIT, too: you can't always depend on having a
preprocessor for IL code, think Reflection.Emit.

lupus

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