I guess i forgot to address your question about what the API would look like. At this moment it looks like this:
!. <Invoke GWT compiler on Module A> 2. <Invoke GWT compiler on Module B> 3. <Invoke GWT compiler on Module C, passing it .gwtlibs from Module's A and B> When compiling Module A I'm not paying attention to which files are or are not modified *at all*. I'm just recompiling every source file known to be part of Module A. I'm leaving it the reponsibility of the build system that is driving the compiler, to know which files have changed and thus know which Modules should be recompiled as a result. I may need to revisit some of that responsibility though, since the current GWT Eclipse plugin owns/manages the GWT compile triggering process. I'm toying with the idea of implementing this iterative compilation triggering responsibility in Maven and (since GWT shouldn't try to act like a build system) then integrating this into the GWT Eclipse plugin? I haven't thought all the way through this part and haven't implemented any of this part yet, so would appreciate suggestions. On Wed, Aug 21, 2013 at 4:29 PM, John Stalcup <stal...@google.com> wrote: > I agree that the fastest executing approach is the approach that does the > least amount of computation. And so yes, your suggestion to "keep a warm > version of the AST loaded in memory, and update that AST on the fly with > just new AST's of changed classes" is a fast design. But there are some > unconsidered questions: do you still have to retranslate the *entire* AST > to Javascript source (and is the resulting process still fast if you have > to do so)? Do the modified files need to trigger generator reruns? How do > you know which generators are/are not affected by the change? When > implementing this incremental generator support, how much duplication will > there be with existing generator logic in the main compile path? > > If you follow this mutative/truly incremental approach in memory in > SuperDev mode, then it's unclear how to reuse this work to also speed up > normal compilation triggered by a build system or continuous integration > server (such as Maven or Jenkins). > > The approach i'm working on is to make change normal compiles to be > incremental at the "per module" level. This should transparently speed up > not just build systems, but also SuperDev mode. > > In a nutshell my approach (leaving out lots and lots of edge cases) is > this: run the GWT compiler on "Module A" with *just* the Java source for > "Module A" and the bytecode for its dependencies provided to the JDT > compiler. Take the results of this compilation and do all of the normal > transformations on it except for optimization (which are currently > inherently global) and write out the resulting Javascript (for just the > types that were provided as Java source) using a special namer that names > types/functions/variables in a globally stable way (so that cross modules > references will resolve at runtime) and write this Javascript into a > ".gwtlib" file. Repeat this for every module in the dependency tree, > starting at the leaf nodes. When you get to the root of the tree, run > global generators and link these precompiled Javascript chunks (that you > pull out of the accumulated ".gwtlib" files) into one big chunk. > > This (should be) fast for 2 reasons: the amount of IO and computation for > each stage is kept to the minimum, and the the global phase is never > analyzing/transforming/outputting a global size AST (it's just > concatenating together the previously compiled Javascript for each of the > dependent modules). It's basically the same process as normal Java > compilation with separate Jar files being constructed. > > It can make cold compiles better by making it possible to parallelize the > compilation of different modules in the module tree, and it can of course > make warm compiles better by requiring only the recompilation of the > particular module that contains the changed file (as well as the rerun of > global generators and linking). User.gwt.xml registers 16 generators, but > I'm expecting that I'll be able to annotate some of them as "known to be > local" so that they can be kept out of the global phase and for the > remaining ones it should be possible to run them partially locally and > partially globally (so as to minimize the size of the global phase). > Eventually it would be nice to deprecate and replace all generators that > require some global phase. > > > > > On Wed, Aug 21, 2013 at 8:34 AM, Stephen Haberman < > step...@exigencecorp.com> wrote: > >> Hey John, >> >> > 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. >> >> Spiffy! Out of curiosity, would the API look something like: >> >> theBackendCompile.recompile(List<File> filesThatChanged) >> >> Such that the existing ResourceOracle/TypeOracle instances are mutated >> with the updated state, instead of being rebuilt? >> >> AFAIK, historically most of the optimizations around "incremental" >> compiles have always required going back to building ResourceOracle, >> TypeOracle from scratch, but speeding it up with caching. >> >> ...IIRC. It's been a little while since I've poked at the code. >> >> I know I'm being a broken record, but I think the mutative/truly >> incremental approach, while a (large) PITA to build, in the long run is >> the only solution that would be fast enough to get SuperDevMode fast >> enough such that it's "hit save in Eclipse, the js file is updated, >> done!", just like Java (and web) developers are used to. >> >> (I know Brian really doesn't like solutions that require Eclipse, but I >> think the same mutative/incremental compiler API could just as well be >> called by an Eclipse plugin or an IDEA plugin or even a Java daemon >> polling the file system for changes. It's not IDE-specific.) >> >> Feel free to ignore my musings given I'm not actually contributing >> anything to the effort; just curious as to how things are going. >> >> - Stephen >> >> -- >> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
