GWT 2.7 SDM incremental output too large

[Jens]

Hi,

Our app produces permutations about 3.5mb in size when doing optimized production builds. It is roughly 150.000 fields across 12.000 types (according to the first SDM incremental compile output). I tried that app with several browsers (all Mac OS) to see how things work with SDM incremental compile:

- Opening the native dev tools of Firefox 33 and switching to the debugger tab freezes Firefox for several (5+) minutes until it finally displays all source mapped java files. And thats for each page reload. Breakpoints work but since you can not see which source line is mapped you might need to guess a bit until you find a spot where the breakpoint actually works (or look it up on the code server). But because of the reload times debugging is literally unusable. Maybe it is possible to use FireFox remote debugging in IntelliJ. Haven't tried that yet.

- Safari 7 also has quite some lag. The reason is that Safari Dev Tools store each XHR request done to fetch a source mapped file from code server. If you now want to search for a Java file in the browser the search lags quite a bit because it also filters all these 1000+ XHR requests. But thats a Safari issue one must accept for now. I also noticed that sometimes the CodeServer responds with 404 for all source mapped files that are generated by GWT generators, e.g.

GET /sourcemaps/app/3427F4D36ECEACFA71B338AB1AE1396C_sourcemap.json

   sent source map for module 'app' in 269 ms

GET /sourcemaps/app/gen/com/google/gwt/cell/client/TextInputCell_TemplateImpl.java

   Sent error page: unknown source file: gen/com/google/gwt/cell/client/TextInputCell_TemplateImpl.java

When I open up the CodeServer web site at <ip>:9876/sourcemaps/app/ I can see an entry for gen/com/google/gwt/cell/client/ . Once I enter it I can see the TextInputCell_TemplateImpl.java however if I want to open it in the browser the CodeServer can not find it and reports an error. Thats something I haven't noticed in Chrome so far.

Finally setting break points in the source mapped Java file does not seem to work at all in Safari 7. Breakpoints are accepted but never hit by the debugger. I tried several different code lines (all are marked as black lines on the code server sourcemap html output so they should have valid mappings).

- In IE 11 it also takes quite some time until source mapped java files appear in the dev tools (similar to FireFox). Once they appear, file filtering is pretty slow but I can live with that. However if I want to set a breakpoint in any of my files then the breakpoint is actually placed in a GWT file called ModuleUtils.java. No idea why but that also makes debugging impossible. Trying to open the pure JS file does not work either.

So in short, although incremental compilation is pretty cool all non Google Chrome browsers have issues with our app because 1.) the pure JS size produced by incremental compile is too large (Safari actually showed the total size of resources downloaded and it shows 75MB) and 2.) handling the source map does not work well and break points might be dead.

For IE we can still use classic DevMode but for FireFox, Safari and mobile browsers debugging doesn't work well for large apps.

-- J.

[Rene Hangstrup Møller]

Our application is roughly the same size (3.5mb) and I have never been able to debug using source maps in firefox. It freezes when it has to load them. I have also tried remote javascript debugging with super devmode from IntelliJ. I can typically step over a couple of breakpoints and then it drops the connection. So I still use DevMode with Firefox 24 ESR when I have to debug.

Works fine in chrome.

Best regards
Rene

[Ray Cromwell]

Post 2.7, we're going to look into pruning down the incremental
output. However, this won't solve poor sourcemap implementations in
other browsers. One option is to get source-map support improved
directly in Eclipse/IntelliJ, so that the Javascript-based developer
tools are not used, rather, the IDEs connect to the Browsers via
remote debugging protocols, but the SourceMap/indexing/navigation is
done by Eclipse/IntelliJ.

> --
> 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-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/69d8d8a2-367e-4339-92fe-708841d23e30%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Rene Hangstrup Møller]

Good point. When I tried remote js debugging with sourcemaps from intellij I thought about the irony og the setup.

You have the source in your IDE. Then you push the source and mappings to the compiled output into the browser, and then you remote control the debugger from the IDE.

It would be awesome if I could just have the browser run the compiled and minimized code, and my IDE could do the mapping between original source and compiled output.

[John Stalcup]

We're planning to do some work (link time pruning) to reduce incremental output size some time before the end of the year.

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e718fd83-c3c7-49b5-8fe3-294622047266%40googlegroups.com.

[Ivan Markov]

 One option is to get source-map support improved
directly in Eclipse/IntelliJ, so that the Javascript-based developer
tools are not used, rather, the IDEs connect to the Browsers via
remote debugging protocols, but the SourceMap/indexing/navigation is
done by Eclipse/IntelliJ.

A shameless plug: this is anyway what SDBG does already now...

Blink's remote debugging protocol has no idea what a sourcemap is, aside from one little string hint telling me what is the name of the sourcemap file associated with script XYZ (which is btw very useful as it saves me from fetching the huge GWT JS output and scanning //# sourceMappingURL=). All the sourcemap parsing and indexing is happening in Eclipse.

Of course it is another topic that as of now, SDBG still only supports Chrome.