mirror of https://github.com/sbt/sbt.git
For projects with a large number of files, zinc has to do a lot of work to determine which source files and binaries have changes since the last build. In a very simple project with 5000 source files, it takes roughly 750ms to do a no-op compile using the default incremental compiler options. After this change, it takes about 200ms. Of those 200ms, 50ms are due to the update task, which does a partial project resolution*. The implementation is straightforward since zinc already provides an api for overriding the built in change detection strategy. In a previous commit, I updated the sources task to return StampedFile rather than regular java.io.File instances. To compute all of the source file stamps, we simply list the sources and if the source is in fact an instance of StampedFile, we don't need to compute it, otherwise we generate a StampedFile on the fly. After building a map of stamped files for both the sources files and all of the binary dependencies, we simply diff these maps with the previous results in the changedSources, changedBinaries and removedProducts methods. The new ExternalHooks are easily disabled by setting `externalHooks := _ => None` in the project build. In the future, I could see moving ExternalHooks into the zinc project so that other tools like bloop or mill could use them. * I think this delay could be eliminated by caching the UpdateResult so long as the project doesn't depend on any snapshot libraries. For a project with a single source, the no-op compile takes O(50ms) so caching the project resolution would make compilation start nearly instantaneous. |
||
|---|---|---|
| .. | ||
| src | ||
| NOTICE | ||