> 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.
>
Yes, the IR came over from the existing design of the ClosureCompiler for
Squeak that Opal is was based on initially… I liked it at first because I was
looking into byte code
manipulation back then and for that it was quite nice.
But for compiling, it adds a layer that is not really needed. If I would do it
again I would not use this IR level in the compiler but instead do something
simpler and use
the BytecodeBuilder directly.
But as Clement notes: it is not that much time when doing compilation if you
consider the whole use-case of compiling, so this seemed not that of a problem
(e.g. for compiling the image, we were happy with a factor 2, I did not
benchmark recently, but I think this is what we reached).
For the frontend (compile to AST + name analysis), it is fast enough to do
syntax highlighting in the browser with it instead of a specialised parser, so
that part is
quite ok.
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.
Marcus
