-
Notifications
You must be signed in to change notification settings - Fork 1
Programmable Classpath to support Pickle caching, Build Pipelining #27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
You can see my implementation of this in sbt/zinc, supported in 2.11, 2.12 and 2.13: https://github.com/scalacenter/zinc/blob/topic/pipelined-parallel-compilation-rebase/internal/compiler-bridge/src/main/scala_2.12-13-only/scala/tools/nsc/ZincPicklePath.scala and https://github.com/scalacenter/zinc/blob/topic/pipelined-parallel-compilation-rebase/internal/compiler-bridge/src/main/scala_2.12-13-only/xsbt/ZincSymbolLoaders.scala (note: I don't implement symbol invalidation) The beauty of having this implemented in Zinc instead of the Scala compiler is that Zinc is compiler agnostic. For example, I can support pipelining in Dotty as soon as the bridge supports this capability. I like the changes in this PR but I wonder if we need this abstraction. At a higher level, all we need to implement pipelining and classpath caching is a way to communicate to the compiler which classpath entries have changed, whether they are class files in a directory or jars. If we add such an interface to the compiler, Zinc could tell the compiler directly which things need to be invalidated, and the compiler will invalidate the symbol table accordingly. I feel this is a better approach because what changes or not is already known by the tools using the compiler (build tools, incremental compiler, IDEs/editors). |
For example, how do you feel about adding the following two compiler settings instead:
|
447fbd3
to
641d2ee
Compare
4b20674
to
1126fd7
Compare
Using https://github.com/guardian/frontend as a test case: Traditional: Pipeliining (via Outline Typing) + Parallel compilation of large sub-projects: The latter has better utilization, but the throwaway work of outline typing has too high a cost in this case. I'm about to implement the variation of build pipelining that grabs the pickles from a regular compilation run instead. (UPDATE: Done) Pipelining (via extracting pickles from regular compilation) |
I've moved the pattern matcher phase after pickler which should slightly improve pipelining efficiency. Build traces for the three strategies above: https://www.dropbox.com/sh/42bzdwag94ywlpo/AACxjoumoDZh0Oolz8t0dymwa?dl=0
|
32e6c60
to
1541fa0
Compare
8b24244
to
83e6a7c
Compare
83e6a7c
to
3e52000
Compare
Provide an extension point for plugins to implement classpath caching and build pipelining.
Part of scala/scala-dev#416