Could not we do a task force to clean the compiler? We need a better infrastructure for the tool.
Stef On Fri, Nov 24, 2017 at 11:35 AM, Nicolas Cellier <[email protected]> wrote: > > > 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. >
