Whilst digging around trying to make some stuff go faster, I noticed something odd... I was getting a bunch of extra types getting marked stale at the beginning of a recompile, and at work, recompiles triggered even when no changes were made to Gwt-related files.
So, a little debugging and I noticed that we're computing the initial stale types using timestamps. And, my IDE (yes, sigh, eclipse) is actually touching the files even when I'm not explicitly saving them. This causes these types to look stale despite there being no changes. When I close my IDE and manually edit a file via text editor, there are no longer extraneous files being marked stale. It is understandable to use timestamps when recalculating stale types after a rebind, but for the initial staleness check in UnifyAst, I think paying a little extra for file hashes instead of time stamps might save a lot of extra time recompiling files that did not actually change. If we want to save some wall time, we could calculate all the initial file hashes in a background thread on the initial compile (or store them as we load them), and then only look at the hashes if there is a timestamp difference. This would let us use timestamps as a heuristic for checking hashes. I'm not sure if IntelliJ has better respect for touching files than eclipse, but it seems like a pretty common use case for a file to get touched without changing. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/6a1af18b-94a2-4814-831a-19ba92b7e6eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
