On Mon, Jun 15, 2009 at 11:52 PM, Ray Cromwell<[email protected]> wrote: > 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?
"Instant hosted mode" seems to mean whatever the team's latest ideas are on making hosted mode go faster. :) Your description of storing more information on disk should help both hosted mode and compiles, because whenever a GWT tool starts up it can skip some steps and read in the partially digested information from previous runs. Some plans are underway to do that for hosted mode. It could also be done for compiles: we could save a little serialized AST for each .java file so that they don't have to be recompiled unless the .java file (or one of its dependencies!) changes. An alternative is to keep the information inside a running process, the way hosted mode currently does. This could be applied for web-mode compiles, but currently isn't. The main tradeoffs I see are that the files version integrates well with existing tools and IDEs. No matter what build tool you use, you should be able to get a fast incremental build by using the files version. On the flip side, for people that manage to get set up with the process version and keep their process running, the refresh speed should be faster than with the files version, because it won't be doing any serialization. A key question for balancing this tradeoff is to what degree people actually manage to keep up their hosted mode process.... Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
