GWTAR files are okay, but are an incomplete solution to the problem of incremental compilation.
During a normal monolithic GWT compile: - ~50% of the time is spent loading Java source off disk, compiling it with JDT, translating the JDT Java AST to a GWT Java AST (1 AST per type), and populating type oracles. - the other ~50% of the time is spent "stitching" the individual type ASTs into one combined tree, running GWT and Javascript semantic normalization passes, running optimization passes, translating GWT Java AST to GWT Javascript AST, translating GWT Javascript AST to Javascript Source and linking to disk. GWTAR has impact by effectively running that first ~50% chunk once per module (using just the Java source available to that module) and serializing the resulting GWT Java ASTs to disk, and reusing these per module GWTAR caches for subsequent compiles. So as a result, in the best possible world the maximum impact it can have on compile time, is ~50%. In practice it has a little less than that because reading and deserializing these GWT Java ASTs from disk takes some (smaller) amount of time and because in large modular projects there's a tendency for duplicate copies of the AST for the same type to accumulate in multiple GWTAR files (thus resulting in wasted duplicate deserialization time). Unlike GWTAR files the incremental compilation approach i'm working on makes/will make 90+% of the compile time split by module (the only time left in the monlithic phase should be a small percentage of generators and the final linking). I don't want to discourage you from using GWTAR files, since they do have positive impact. But I'm just saying that I'm not putting work into making them easier to use or building easier build system integration for them, since their maximum impact is limited. On Wed, Aug 21, 2013 at 12:05 AM, James Nelson <[email protected]> wrote: > re: Heiko Braun > >> >> it means having an optional compilation path that does not recompile the >> entire world (as the current monolithic compile path does) and instead >> tries to recompile just files (or or modules) that have changed. >> >> it is exploratory work for me right now as there are very many issues >> standing in its way. >> >> if/when it is done and ready it should make a big impact on SuperDev mode >> refresh time by reducing compile time (when compiles are run >> non-monolithically) >> >> > I've long felt like highly modular projects could greatly benefit from > producing gwtar files so that unchanged code does not require recompiling. > I've thought about using a maven plugin to add .gwtar to my jars, though > this would not be a portable solution for all GWT developers. > > Any portable solution using gwtar would be to create one per module (using > a flag to enable support while still experimental), or one per java package > (maybe not a good idea given the size of some projects). > > Given that the compiler already knows to remove invalidated units, this > does seem like a feasible option. > Producing .gwtars could also be done periodically for the whole project at > the developers whim, perhaps through a flag to a standard full compile? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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]. For more options, visit https://groups.google.com/groups/opt_out.
