> 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.
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).