Dear GWT team (and John in particular), Lately I was checking from time to time the progress of the SDM incremental compiler in GWT 2.7.0.
Let me first say - great work so far! This morning our project was - for the first time - compilable with the new incremental SDM code-path, without internal compiler errors or visible malfunctioning. And this with NO changes to the codebase. Also the fact that I don't have to split our codebase into very many small acyclic modules (not that it is not a good practice anyway) is obviously a HUGE PLUS. What I am observing in terms of recompilation times is encouraging (25 seconds with 2.7 vs. 47 with 2.6.1) but what is even more interesting is that the compilation itself (up until where it says "Compile of permutations succeeded") seems to take only 7 seconds, which is less than 30% of the recompilation time. In other words, with the new incremental compiler, the biggest slowdown during recompilation seems to be the linker now, right? If the linking time can go down to, say, a couple of seconds, then SDM is there (IMO). So out of pure curiosity - are there obvious optimizations in the linker which are still pending? For example, I noticed that a huge amount of time (> 50% of the whole linking time) is spend in "Saving source with extras", i.e. SourceSaver. Given that these sources are only needed by the browser during a sourcemap-based debugging session, can't they be served on the fly by the code server rather than being pregenerated on disk during the recompilation? There are debugging scenarios (in-IDE debugging with SDBG), where these source files are not even needed and never requested from the codeserver. Also, is there any way to accelerate the linker which is in the control of the developer? For example, can I turn off the above source files pregeneration to see how much time is saved during recompilation? ================= Finally one side question: Does the incremental compiler preserve the names of the generated JavaScript types/functions across recompiles? Including the names of the types/functions which ARE recompiled (as long as the programmer did not change the name of the corresponding Java method/class, that is)? Because if it does, this opens interesting possibilities: (a) Javascript hot-swapping One disadvantage of the current SDM recompilation is that it triggers page reload in the browser. If the application being debugged is a stateful, single-paged one, this means that even for a very small change, the developer essentially starts-over the debugging, as the application state is lost. Now, the debugging protocol of Blink allows the debugger to hot-swap a piece of JavaScript with a newer version, right? If the incremental compiler preserves the names of the generated Javascript types/functions, then a debugger like SDBG can detect the SDM recompilation and can pro-actively push the newly generated JavaScript into the browser. Imagine how cool is this: you stay on the page, spot a bug (say, in an onclick event handler), fix the bug in the Java code, hit the Recompile button (or Eclipse/SDBG does it for you behind the scenes when you save your Java file!) and there you have it - you can click again and now the correct, recompiled event handler will be triggered. All of this without leaving the application page and starting over. Of course, for the above to work, additional changes may be necessary. For example, contrary to production, the generated javascript file should probably always be named the same way. Perhaps, it should also not contain one big "eval" statement. Finally, for big changes, the above hot-swapping will likely not work, but the idea is not to make it work in all cases, but for the majority of the small, incremental changes. (b) On the fly evaluation of Java expressions in the debugger The challenge here is that the expression being evaluated must be compiled as if it is already part of the GWT application (i.e. if it refers to application's classes, methods fields etc., it should be with their correct javascript names). This sounds like a perfect fit for the incremental compiler - how about a new HTTP service point in the codeserver? Say, something like http://localhost:<port>?eval=<Java-expression-or-if-required-whole-Java-type>, which outputs, as a response, a valid JavaScript block of code which can be evaluated by the debugger? SDBG (or other debugger) will then use the SDM codeserver as a compiler of sorts for the expression entered by the user during debugging. I'm surely missing something - for example the evaluated expression needs to be capable of accessing the variables on the currently selected stackframe in the debugger, but if Eclipse's Java debugger is capable of doing that without special support in the Java debugging protocol, then it should be possible for our case as well. What do you think? -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5a2a4436-5c2d-4e60-9d5d-314db0045b7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
