diff options
author | Guillaume Martres <smarter@ubuntu.com> | 2018-07-27 22:29:51 +0200 |
---|---|---|
committer | Li Haoyi <haoyi.sg@gmail.com> | 2018-07-28 04:29:51 +0800 |
commit | fa6987b5bff17640985ce0ab4d07440ef1189c45 (patch) | |
tree | 15d84ea24d703172c2303f5368b0229325e061e7 /docs/pages/2 - Configuring Mill.md | |
parent | 450679672077a5d96e572e2526680db7ae3a1dcb (diff) | |
download | mill-fa6987b5bff17640985ce0ab4d07440ef1189c45.tar.gz mill-fa6987b5bff17640985ce0ab4d07440ef1189c45.tar.bz2 mill-fa6987b5bff17640985ce0ab4d07440ef1189c45.zip |
Make hot compilation 2x faster by properly reusing classloaders (#393)
So far, Mill was caching ScalaInstance which contains a classloader but
this is not enough: Zinc creates its own classloader by combining the
ScalaInstance classloader with the path to the compiler-bridge. Zinc
takes care of caching this classloader in each instance of
ScalaCompiler.
We can take advantage of this by caching an instance of Compilers since
it contains everything we want to cache (ScalaCompiler and
ScalaInstance).
This significantly reduces the amount of classloading that happens
at each compilation step, as measured by running:
export _JAVA_OPTIONS="-XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+TraceClassUnloading"
mill -i foo.compile
Then looking at the output of `out/mill-worker-1/logs` while adding a
new line in a source file in `foo` and running `mill -i foo.compile` again.
The speedup is going to depend on the project, but I measured a ~2x
improvement when running on the Mill build `time(core.compile())` and
`rm -rf out/core/compile/` in a loop until results stabilized. See also
the results that were obtained when a very similar issue was fixed in
sbt itself: https://github.com/sbt/sbt/pull/2754
Diffstat (limited to 'docs/pages/2 - Configuring Mill.md')
0 files changed, 0 insertions, 0 deletions