> On 24 Nov 2017, at 10:54, Marcus Denker <marcus.den...@inria.fr> wrote: > > > >> On 23 Nov 2017, at 23:37, Clément Bera <bera.clem...@gmail.com> wrote: >> >> Hi Nicolas. >> >> Just some comments: >> >> Another thing you can try is to remove the allocation of Opal's IR. It seems >> people use the IR only through the IRBuilder, so the API can be kept but it >> can generate directly bytecode instead of IR then bytecode. Removing those >> allocations would speed things up. It means merging IRFix / IRTranslator / >> IRBytecodeGenerator somehow and have the IRBuilder API directly call the new >> resulting merged class. >> >> Another thing is that when Opal became the default compiler, I evaluated the >> speed and saw it was slower, but when loading large projects it seemed >> loading time was dominated by Monticello / source reading / source loading >> and the compilation time was overall not that significant (< 20% of time). I >> don't know if this is still the case with GIT. I have problems currently >> when editing some large methods (it seems in the IDE the method is compiled >> at each keystroke...) and when doing OpalCompiler recompileAll (which I do >> often since I edit bytecode sets) but else the performance of Opal seems to >> be OK. Evaluate performance may be relevant in some cases but I've never >> found such cases outside of the IDE in production. >> > (old mail… late answer).
In the meantime we found out that #recompileAll was recompiling meta-classes twice, with that fixed rempiling is a little bit faster (from around one minute to 50 seconds on my machine). > > One other thing that needs cleanup: the API/ OpalCompiler class. This tries > to be compatible with the old API (e.g. failBlock) and got quite hacked to > death over > time… we should clean that up. The complexity of #evaluate is partly due to > that, I think. > As a first step, I changed #evaluate to not store sources in the trailer, this means that we do not pretty-print the source anymore. https://github.com/pharo-project/pharo/pull/880 The only downside is that a (not very practically relevant) test failed (#testSourceNodeOptimizedBlock). I think we can ignore that for now and fix it when it turns out to be a problem (the test works fine when rewritten to compile a full method). Marcus
