The Play Template compiler is too slow for interactive use #50
Comments
|
I'm not against it, but first we will have to create some spec of the format ... 😕 |
|
Noticed this behavior too, especially in files containing a compilation error. |
|
Hi @dragos, any insight of how to tackle this rewrite? Is the presentation compiler a good example to dive in? |
|
@aldenml, what I have in mind is a plain old recursive descent parser. The Scala parser is one example, but probably way too complex to start with. |
|
@dragos I was taking a deep look to ScalaTemplateCompiler and Parsers (from Scala nsc). It seems to me that ScalaTemplateCompiler (directly copied from Play2) is using an outdated (not so fast) API and could be reimplemented using the new compiler framework (avoiding the combinators based JavaTokensParser). It would be ideal to perform this change in sync with the Play2 team. This change alone could improve the performance issue. The other point is that this "template compiler" is used as part of the code generation with every template file change. I didn't have the time to review what happens if you use Play2 with Java, btw. Do you think it is a viable path first fix/improve what is already in place before creating another compiler? @skyluc Do you know where can I find documentation about creating unit tests for this kind of hard UI-Core issue? |
|
@aldenml, on a cursory inspection, the parser here doesn't look very different from the one we forked a few months ago. I am not terribly fond of combinator parsers, but if you think they can be made fast, why not. Regarding contributing it back upstream, we'd be very happy to do that, of course. I imagine that the parser should be disentangled from the code-generating part. If the AST stays the same, the current code generator can be reused. As for tests, there's nothing UI specific here, so if there's a test suite in Play, it should be able to pass that. And we should also make sure it's sufficiently fast (the benchmark remains to be decided) |
|
Just to make myself more clear. The current ScalaTemplateCompiler is from a PR I made, I just copy/paste-ed the source code from Play2. Its the original "compiler" in Play2 that its based on combinators and a bit outdated. They will see an improvement if the compiler is moved to the new nsc, IMO. In any case, this is not an easy task. |
|
Ah, so it's you! :) Anyway, since the template parser does not need to parse scala source, but only a few syntax elements and the |
|
Well, yeah...:) I need to study more about the plugin to follow this thread (specially the template source code generation) |
|
@aldenml, I didn't mean to discourage you! I am happy to clarify any points I made (maybe we can take this to the scala-ide-dev@ mailing list). |
|
@dragos Sure! and I'm very motivated, now that I see a lot of activity towards a release. I need more time to study in deep this part and I will post any generic question in the mailing list. |
|
I noticed that the compiler is called about 4X for each keystroke in the editor (2 with the old content and 2 (or 1) with the new one). Optimizing this will help a lot. |
|
@aldenml that's a good starting point indeed! Not sure what's going on.. |
|
I've come across the same issue in writing the structured text template editor. For example, try button smashing in this file: https://github.com/playframework/Play20/blob/master/samples/scala/computer-database/app/views/list.scala.html You will see that the editor very noticeably lags behind keystrokes. I performed a cpu sampling, and by far and large all of the time spent was in the parser combinator library. Just reiterating this information here to remind us to replace the parser soon :-). |
We need to rewrite the template compiler. The current version, based on parser combinators, is too slow to be used in the IDE. One example (about 200ms between each keystroke), caught by Svelto:
The text was updated successfully, but these errors were encountered: