On 24 Nov 2017, at 10:54, Marcus Denker <marcus.denker@inria.fr> wrote:
On 23 Nov 2017, at 23:37, Clément Bera <bera.clement@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