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 -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
