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 2:09 PM, John A. Tamplin <[email protected]> wrote: > On Wed, Aug 21, 2013 at 11:34 AM, Stephen Haberman < > [email protected]> 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 let's say you change file A. How do you know what all > needs to be updated in TypeOracle? I am sure you can keep track of it, but > it will require keeping much more data than is currently kept so you can > incrementally update TypeOracle's data structures. For example, let's say > you remove an interface from a class. Even if you walk down the > inheritance tree, you can't just remove that interface, because some other > ancestor might have implemented it. The same sort of thing goes in many > other places. > > Note that TypeOracle memory requirements has been a problem in the past > for large internal apps. > > -- > John A. Tamplin > > -- > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
