On Monday, August 18, 2014 7:14:38 AM UTC-7, Ivan Markov wrote: > > 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. > That's great to hear :). We're pretty happy with the recent progress as well.
> > 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? > Yes, we've come to the same conclusion and Roberto is working on the linker speed right now. > 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)? > Yes, names in this mode are now consistent for the life of that SuperDevMode process (see https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/js/JsPersistentPrettyNamer.java). > > 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. > It does sound like an interesting idea. If at some point the browser reload time (as opposed to the compile time) is the longest part then we will start looking at ways to speed that up. One similarish idea we've discussed is to change the linkers so that the output JS exists as separates files. This would allow the browser to hold on to it's precompiled javascript cache for parts of the application that haven't changed (thus reload much faster). But as Ray mentions, we're pretty heads down on an earlier stage of development right now. So I probably won't be looking at something like this any time soon, but patches welcome. What I am working on is trying to flesh out the "maturity" of this current approach. At the moment we do not notice when you change the content of resource files which were inputs to Generators and so as a result we fail to rerun those Generators when we should. Once this is corrected there will be a while spent on general bug finding. After that we will probably start looking at remaining performance bottlenecks. Roberto is already looking at Linkers and we think that the next big opportunity after that will be in improving the TypeOracle construction time (see https://gwt.googlesource.com/gwt/+/master/dev/core/src/com/google/gwt/dev/javac/CompilationUnitTypeOracleUpdater.java and related classes). But there will probably be other opportunities as well. > (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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e4cf05c1-b709-40b1-aca0-a4459044ce2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
