Hi John,
Thanks for the great responses.
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)?
Yeah, good question...seems like in an ideal world you could cache the
JS string for each compilation unit and then
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
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:
On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman step...@exigencecorp.com
wrote:
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.
The problem is
Hi John,
Thanks for reminding me about this...
The problem is let's say you change file A.
Two things:
First is that AFAIK GWT already does this...see the Dependencies class,
which I became familiar with when trying to build a list of dependencies
for Scala-GWT ASTs so they could fit in this
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
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
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
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
@Johannes Barop
Your approach is interesting since it allows you to avoid cache the results
of generator execution and not have to reparse and recompile generated code
during every monolithic compile. But since it's all based on GWTAR, you're
still limited to a maximum possible impact of 50%.
Agreed. The TypeOracle (actually there are many TypeOracles) indexes, AST
references, JProgram indexes, after optimization, etc etc, are extensive
and complex. Updating them in place when swapping out the AST for a
particular Type would be very tricky and failure prone.
On Wed, Aug 21, 2013 at
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
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
Regarding hello world app running using separate compilation: can you
elaborate on that? Do you mean support for two distinct compilation units
within the same page?
Regards,Heiko
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are
I haven't been sending out emails for our meetings. Let's catch up:
August 7th:
- John got a hello world app running using separate compilation. We
talked a bit about how it might get pulled back into GWT.
- Brian: Firefox architecture changes may break the Development Mode plugin
by the end of
15 matches
Mail list logo
