2017-11-24 10:54 GMT+01:00 Marcus Denker <[email protected]>: > > > > On 23 Nov 2017, at 23:37, Clément Bera <[email protected]> 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.
