Figure out a way to avoid recompiling the predefs all the time #542
Comments
jhnsmth
added a commit
to jhnsmth/Ammonite
that referenced
this issue
May 21, 2017
- Fix `initialClasspathSignature`: - Un-break `skipSuspicious`, whose boolean was flipped and was skipping entirely the wrong folders when traversing classpath folders - Start stat-ing `.jar` files on the class path, since there typically aren't that many so we might as well - Convert the predef definition information from a tuple into a `PredefInfo` object, which has a `hardcoded: Boolean` field - `PredefInfo`s with `hardcoded=true` means that predef doesn't need to be recomputed if the underlying classpath changes. Those are only depended on Ammonite version, and are guaranteed not to depend on third party libs or user code. - Fast-path empty string (`""`) predefs to avoid compiling/loading them at all - Break up `predef` into `defaultPredef` and `commandLinePredef`, where `defaultPredef` has `hardcoded=true` and `commandLinePredef` is usually empty, generally avoiding recompiling both
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: