Would it not be possible to store the Unified/Precompiled/Unoptimized AST to disk and then you'd only have to JDT-reparse any classes that changed? Or use, was it Toby?'s, old idea of tunneling compiler information in .class files on disk (e.g. have the GWT compiler store the AST as some extra segment of the .class file)? Is this how Instant Hosted Mode works? If so, can't it be used for web-mode compiles as well?
-Ray On Mon, Jun 8, 2009 at 10:41 AM, Lex Spoon<[email protected]> wrote: > > On Fri, Jun 5, 2009 at 6:27 PM, Ian Petersen<[email protected]> wrote: >> 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. > > Sounds good to me. It works even better if there is a non-optimizing > mode. A non-optimizing, "always on" compiler could really scream. > > Lex > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
