[Pharo-dev] OpalCompiler evaluate speed

Stephane Ducasse stepharo.self at gmail.com
Sat Nov 25 02:03:07 EST 2017

Could not we do a task force to clean the compiler?

We need a better infrastructure for the tool.


On Fri, Nov 24, 2017 at 11:35 AM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 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.

More information about the Pharo-dev mailing list