Right now, if you use Ammonite in an existing SBT project with a constantly changing classpath (e.g. because you're editing it), you find it constantly recompiling all the predef files whenever it starts:
Compiling replBridge.sc
Compiling interpBridge.sc
Compiling HardcodedPredef.sc
Compiling ArgsPredef.sc
Compiling predef.sc
Compiling SharedPredef.sc
Compiling LoadedPredef.sc
Welcome to the Ammonite Repl 0.8.1
(Scala 2.12.0 Java 1.8.0_112)
@
This is because Ammonite uses the hash of the existing classpath to decide whether things need to be recompiled (in case some definition changes in a binary incompatible way).
However, many of the predefs never depend on user code (replBridge.sc, interpBridge.sc, HardcodedPredef.sc) and really only need to be compiled only once per version of Ammonite. Others (ArgsPredef.sc, predef.sc, SharedPredef.sc, LoadedPredef.sc) are often empty, and thus can also be skipped entirely when they don't contain any code.
When using Ammonite standalone, the caching it good enough to compile these things only once (since the starting classpath of the standalone executable doesn't change much) but we really should make this better to speed up the start time of using Ammonite as part of an existing project.
The text was updated successfully, but these errors were encountered:
Right now, if you use Ammonite in an existing SBT project with a constantly changing classpath (e.g. because you're editing it), you find it constantly recompiling all the predef files whenever it starts:
This is because Ammonite uses the hash of the existing classpath to decide whether things need to be recompiled (in case some definition changes in a binary incompatible way).
However, many of the predefs never depend on user code (
replBridge.sc
,interpBridge.sc
,HardcodedPredef.sc
) and really only need to be compiled only once per version of Ammonite. Others (ArgsPredef.sc
,predef.sc
,SharedPredef.sc
,LoadedPredef.sc
) are often empty, and thus can also be skipped entirely when they don't contain any code.When using Ammonite standalone, the caching it good enough to compile these things only once (since the starting classpath of the standalone executable doesn't change much) but we really should make this better to speed up the start time of using Ammonite as part of an existing project.
The text was updated successfully, but these errors were encountered: