[Pharo-dev] OpalCompiler evaluate speed

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Nov 24 05:35:38 EST 2017


2017-11-24 10:54 GMT+01:00 Marcus Denker <marcus.denker at inria.fr>:

>
>
> > On 23 Nov 2017, at 23:37, Clément Bera <bera.clement at 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.
>

Agree

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

Yes, that was exactly my feeling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171124/91dd2855/attachment-0002.html>


More information about the Pharo-dev mailing list