Ever since I started using Eclipse, I've always thought that compilers and make systems should be "always on". I'd bet an incremental build would be hard to pull off first time around, but an always-on GWT compiler could at least keep the initial JDT parse tree alive somewhere (in RAM if it's not huge, on disk if it is) and update it on-demand by monitoring the filesystem for changes (at least in theory--I haven't looked at the compiler internals). Ideally, there'd be some sort of caching mechanism that could be invalidated by filesystem changes so you could store optimized JS ASTs, too, so you save on parsing _and_ compiling, but that seems like a v2 feature.
Ian On Fri, Jun 5, 2009 at 2:13 PM, Isaac Truett<[email protected]> wrote: > >> Of course, if we ran the GWT compiler as a service on the developer's >> desktop (or kept it hot from the Eclipse plugin), then we could run it with >> -server and win it back over many compiles... hmmm. :) > > Would keeping that VM alive open up the possibility of a semi-incremental > build? > > > On Fri, Jun 5, 2009 at 1:52 PM, Scott Blum <[email protected]> wrote: >> On Fri, Jun 5, 2009 at 1:47 PM, Lex Spoon <[email protected]> wrote: >>> >>> Reading further in the thread, though, maybe we should simply use -server! >> >> Funny enough, I used to use -server in all my launch configs, but at some >> point I found it seemed actually a lot slower most of the time, due to all >> the overhead. I think you need a really big compile to make it worth it >> (30-perm Showcase might be worth it, the other samples probably not). >> Of course, if we ran the GWT compiler as a service on the developer's >> desktop (or kept it hot from the Eclipse plugin), then we could run it with >> -server and win it back over many compiles... hmmm. :) >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
