Fix #433: Make classpath hashing more lightweight #452

jvican · 2017-11-09T15:50:25Z

And make it parallel!

This patch adds a cache that relies on filesystem metadata to cache
hashes for jars that have the same last modified time across different
compiler iterations. This is important because until now there was a
significant overhead when running compile on multi-module builds that
have gigantic classpaths. In this scenario, the previous algorithm
computed hashes for all jars transitively across all these projects.

This patch is conservative; there are several things that are wrong with
the status quo of classpath hashing. The most important one is the fact
that Zinc has been doing hashCode on a SHA-1 checksum, which doesn't
make sense. The second one is that we don't need a SHA-1 checksum for
the kind of checks we want to do. #371
explains why. The third limitation with this check is that file hashes
are implemented internally as ints, which is not enough to represent
the richness of the checksum. My previous PR also tackles this problem,
which will be solved in the long term.

Therefore, this pull request only tackles these two things:

Caching of classpath entry hashes.
Parallelize this IO-bound task.

Results, on my local machine:

No parallel hashing of the first 500 jars in my ivy cache: 1330ms.
Parallel hashing of the first 500 jars in my ivy cache: 770ms.
Second (cached) parallel hashing of the first 500 jars in my ivy cache: 1ms.

fommil · 2017-11-09T16:10:28Z

can you please validate against the demo project at https://github.com/cakesolutions/sbt-cake/tree/sbt-perf-regression ?

I have no idea how to run a custom zinc, so I am unable to do so. Hence the monkey patch PRs to sbt.

fommil · 2017-11-09T16:12:54Z

zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala

@@ -162,6 +165,13 @@ final class MixedAnalyzingCompiler(
 * of cross Java-Scala compilation.
 */
 object MixedAnalyzingCompiler {
+  private[this] val cacheMetadataJar = new ConcurrentHashMap[File, (FileTime, FileHash)]()


this will leak... you need to use something like a Gauva weak cache.

Also I recommend using Path instead of File, because it has a much smaller memory footprint.

In fact File (and URL) are the biggest heap hogs in sbt on large projects... mostly because the path prefix is duplicated. I'm talking GBs.

You're right that I should use a path here. I'll use a Synchronized map wrapping a weak cache ref. Ironically that was my first approach but didn't quite like it.

doesn't sbt have a synchronised weak cache already?

Not to the best of my knowledge...

Finally, I've decided not to use a synchronize weak map here. We could get fancy, but this cache is only for jars and it's going to have tops 1000 entries. So I'll keep it as it is.

fommil · 2017-11-09T16:13:41Z

zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala

-      FileHash.of(x, Stamper.forHash(x).hashCode)
+    val parallelClasspathHashing = classpath.toParArray.map { file =>
+      val attrs = Files.readAttributes(file.toPath, classOf[BasicFileAttributes])
+      val currentFileTime = attrs.lastModifiedTime()


using size as well as modified is effectively free at his point (it's in attrs) so we could use it to be safe.

fommil · 2017-11-09T16:14:36Z

zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala

@@ -181,9 +191,16 @@ object MixedAnalyzingCompiler {
      incrementalCompilerOptions: IncOptions,
      extra: List[(String, String)]
  ): CompileConfiguration = {
-    val classpathHash = classpath map { x =>
-      FileHash.of(x, Stamper.forHash(x).hashCode)
+    val parallelClasspathHashing = classpath.toParArray.map { file =>


.toParArray? Is there a better way? The parallel collections rarely speed things up. Certainly hitting the cache in parallel will be slower.

Perhaps parallelisation can be done in a follow up so its impact can be isolated?

That's not my experience. Parallel collections do speed things up and they're reliable. I can tell you hitting the cache is not slower, I've done measurements locally.

Even for 10 jars, doing it in parallel is faster than doing it in serial.

It might be worth comparing the performance on an SSD versus a mechanical disk. It depends on a lot of factors (and I've no idea how modern technology mitigates them), but parallelizing IO operations on a mechanical disk might actually slow it down.

In my experience, IO-bound operations yield very good results when they're parallelized. I think there are old textbooks on parallel computing that claim so too, before the pre-SSD era.

In any case, I benchmarked it just in case in a LAMP server. Results:

Parallelized hashing: 549ms.

Serial hashing: 1912ms.

I'm testing it on /dev/vda, which as you see is a rotational disk:

platform@scalagesrv2:~/tests/zinc$ lsblk -d -o name,rota NAME ROTA fd0 1 sr0 1 vda 1

jvican · 2017-11-09T16:16:45Z

@fommil I will not validate it myself. I have already a test that proves this works. If you're interested in checking this fix out, you can publish zinc, change the zinc version in sbt/sbt, publish sbt/sbt locally and use that version in build.properties.

fommil · 2017-11-09T16:22:20Z

I tried that process, but lost several hours, and then gave up and basically did this

leonardehrenfried · 2017-11-09T17:05:45Z

zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala

@@ -162,6 +165,17 @@ final class MixedAnalyzingCompiler(
 * of cross Java-Scala compilation.
 */
 object MixedAnalyzingCompiler {
+  private type JarMetadata = (FileTime, Long)
+  // Using paths instead of files as key because they have more lightweight memory consumption
+  private[this] val cacheMetadataJar = new ConcurrentHashMap[File, (JarMetadata, FileHash)]()


Doesn't the code do something different from what the comment says? The key is a File.

and that is why comments SUCK

Yup, that's a stale comment, thanks for the catch.

fommil · 2017-11-09T17:22:39Z

zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala

-      FileHash.of(x, Stamper.forHash(x).hashCode)
+    // #433: Cache jars with their metadata to avoid recomputing hashes transitively in other projects
+    val parallelClasspathHashing = classpath.toParArray.map { file =>
+      if (!file.exists()) emptyFileHash(file)


I'm pretty sure you can use the file attributes on a non-existent file and then use the response to detect existence... if that is the case it would be best to use it here and avoid a stack frame (which is slow on windows so best to batch / minimise all I/O calls)

I was just getting IO errors because of this, it was unintuitive to me too.

@fommil I got a proof, /caca/peluda does not exist:

scala> val attrs = java.nio.file.Files.readAttributes((new java.io.File("/caca/peluda").toPath), classOf[BasicFileAttributes]) java.nio.file.NoSuchFileException: /caca/peluda at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55) at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144) at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99) at java.nio.file.Files.readAttributes(Files.java:1737) ... 28 elided

ok cool, that's good to know.

stuhood

Looks fine from my perspective, although aligning more cleanly with #427 would be good.

stuhood · 2017-11-09T18:23:37Z

zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala

@@ -162,6 +165,17 @@ final class MixedAnalyzingCompiler(
 * of cross Java-Scala compilation.
 */
 object MixedAnalyzingCompiler {
+  // For more safety, store both the time and size
+  private type JarMetadata = (FileTime, Long)
+  private[this] val cacheMetadataJar = new ConcurrentHashMap[File, (JarMetadata, FileHash)]()


Given that #427 is in, it would seem that all of this code should be located on the companion object of the "default" implementation of hashing. Put it in the top of MixedAnalyzingCompiler makes that class into more of a grabbag.

By the companion object of the default implementation of hashing, do you mean FileHash or Stamper? It's not clear to me we want to reuse this code across all the users of IOHash or FileHash.

If there isn't a relevant companion class, then I guess my suggestion would be to define a new one. Not a blocker. Just that logically I would expect this to look something like:

val hashingStrategy = if (flag) DefaultStrategy else UserDefinedStrategy(...) ???

But looking at it again, ExternalHooks doesn't make it possible to do this. So only the "grabbag" part is really relevant.

I agree it looks like a grabbag, so it's better to move it somewhere else. thanks for the suggestion 😄.

@stuhood I've implemented your suggestion 😉. The Zinc API has been historically such a mess that sometimes I forget it can and should be improved 😄.

fommil · 2017-11-09T18:37:08Z

is this PR against the 1.0.x line or 1.1 line?

I think you might need to backport to 1.0.x if it could be included in an sbt point release.

jvican · 2017-11-09T18:37:51Z

It's in the 1.0.x line.

jvican · 2017-11-09T18:42:49Z

I've just realized that #427 is in 1.x, and I need to backport it to 1.0.x before I apply my patch. I think it would be a good idea to revisit all this 1.0.x and 1.x thing...

fommil · 2017-11-09T19:43:36Z

@jvican yeah that's what I thought. But you don't need to backport 427 for this. You can just implement this as the default and that won't impact the binary API for 1.0.x.

jvican · 2017-11-09T20:01:04Z

Right, that's better @fommil. This will be shipped in a minor release, so it's better to avoid breaking bincompat in 1.0.x and then adapt @romanowski's approach to my PR.

And make it parallel! This patch adds a cache that relies on filesystem metadata to cache hashes for jars that have the same last modified time across different compiler iterations. This is important because until now there was a significant overhead when running `compile` on multi-module builds that have gigantic classpaths. In this scenario, the previous algorithm computed hashes for all jars transitively across all these projects. This patch is conservative; there are several things that are wrong with the status quo of classpath hashing. The most important one is the fact that Zinc has been doing `hashCode` on a SHA-1 checksum, which doesn't make sense. The second one is that we don't need a SHA-1 checksum for the kind of checks we want to do. sbt#371 explains why. The third limitation with this check is that file hashes are implemented internally as `int`s, which is not enough to represent the richness of the checksum. My previous PR also tackles this problem, which will be solved in the long term. Therefore, this pull request only tackles these two things: * Caching of classpath entry hashes. * Parallelize this IO-bound task. Results, on my local machine: - No parallel hashing of the first 500 jars in my ivy cache: 1330ms. - Parallel hashing of the first 500 jars in my ivy cache: 770ms. - Second parallel hashing of the first 500 jars in my ivy cache: 1ms. Fixes sbt#433.

godenji · 2017-11-11T16:56:25Z

So I just pulled this PR; published local Zinc snapshot along with Sbt snapshot that uses it.

Not seeing any difference wrt to hashing time, sbt.io.Hash$.apply consumes same amount of time as with Sbt 1.0.3/Zinc 1.0.

Here's a Visualvm screenshot (running compile several times in succession).

Maybe this PR solves a different problem? sbt -Dsbt.task.timings=true shows all of the time is spent in compileIncremental; this in a 30kloc app spread across 650 scala source files with 30 subprojects.

jvican · 2017-11-11T22:16:02Z

@godenji Are you sure you've correctly published local Zinc and sbt? I really recommend to double check that, and change the versions as much as possible to avoid problems with cached jars. Make sure you use an sbt version that hasn't been used before.

Since I don't have access to your project, it would really help if you can instrument this PR to report data and identify which classpath entries are being cached and which are not, as well as auxiliary useful information.

godenji · 2017-11-11T22:27:31Z

Are you sure you've correctly published local Zinc and sbt?

@jvican I considered that, but after blowing away ~/.ivy2/local/org.scala-sbt/ the non-change in performance persists. Starting up test project (vanilla giter8 play project) does show sbt pulling in the local artifacts (e.g. "using local for ... zinc-compiler-1.1.0-SNAPSHOT"), and published source jars do reflect the changes in this PR.

I'll dig around some more, bottleneck may be elsewhere than what this PR resolves.

jvican · 2017-11-12T15:56:59Z

@godenji You also need to blow away the corresponding folder in ~/.sbt/boot. I encourage you to use a completely different version, something like 37.1.1-jar-change.

godenji · 2017-11-12T16:14:11Z

You also need to blow away the corresponding folder in ~/.sbt/boot

@jvican that was it, noop compile now takes 0ms, yes ;-)

Since this is going into Zinc 1.0.x and Sbt 1.0.4 is slated for this coming week, is there any chance that this magnificent fix can make its way into Sbt? That would be most welcome, incremental builds are horrendous ATM.

jvican · 2017-11-13T13:13:09Z

I've benchmarked this in a personal project too and I confirm it's fixed. Thanks for volunteering to try this out @godenji.

jvican · 2017-11-13T18:26:39Z

@eed3si9n Can you review this please 😄?

eed3si9n

LGTM
I like that the change is contained to implementation side.

Duhemm

LGTM

* 1.0.x: (25 commits) Add yourkit acknoledgement in the README Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 Fix source-dependencies/sealed Import statement no longer needed Move mima exclusions to its own file ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt#393 (a 1.x PR), conflicting with * sbt#446 (a 1.0.x PR). The MixedAnalyzingCompiler conflict is due to: * sbt#427 (a 1.x PR), conflicting with * sbt#452 (a 1.0.x PR).

* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt#393 (a 1.x PR), conflicting with * sbt#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (sbt#413, sbt#418, sbt#453). The MixedAnalyzingCompiler conflict is due to: * sbt#427 (a 1.x PR), conflicting with * sbt#452 (a 1.0.x PR).

typesafe-tools · 2017-11-25T10:19:33Z

The validator has checked the following projects against Scala 2.12,
tested using dbuild, projects built on top of each other.

Project	Reference	Commit
sbt	1.x	sbt/sbt@`c517517`
zinc	pull/452/head	`a90a0e9`
io	1.x	sbt/io@`e8c9757`
librarymanagement	1.x	sbt/librarymanagement@`163e8bf`
util	1.x	sbt/util@`f4eadfc`
website	1.x

✅ The result is: SUCCESS
(restart)

* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix #332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix #442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix #436: Remove annoying log4j scripted exception Fix #127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt/zinc#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt/zinc#393 (a 1.x PR), conflicting with * sbt/zinc#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (#413, #418, #453). The MixedAnalyzingCompiler conflict is due to: * sbt/zinc#427 (a 1.x PR), conflicting with * sbt/zinc#452 (a 1.0.x PR).

* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt/zinc#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt/zinc#393 (a 1.x PR), conflicting with * sbt/zinc#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (sbt#413, sbt#418, sbt#453). The MixedAnalyzingCompiler conflict is due to: * sbt/zinc#427 (a 1.x PR), conflicting with * sbt/zinc#452 (a 1.0.x PR).

* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix scala#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix scala#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix scala#436: Remove annoying log4j scripted exception Fix scala#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt/zinc#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt/zinc#393 (a 1.x PR), conflicting with * sbt/zinc#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (scala#413, scala#418, scala#453). The MixedAnalyzingCompiler conflict is due to: * sbt/zinc#427 (a 1.x PR), conflicting with * sbt/zinc#452 (a 1.0.x PR).

* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix scala#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix scala#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix scala#436: Remove annoying log4j scripted exception Fix scala#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt/zinc#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt/zinc#393 (a 1.x PR), conflicting with * sbt/zinc#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (scala#413, scala#418, scala#453). The MixedAnalyzingCompiler conflict is due to: * sbt/zinc#427 (a 1.x PR), conflicting with * sbt/zinc#452 (a 1.0.x PR). Rewritten from sbt/zinc@e245d95

eed3si9n added the in progress label Nov 9, 2017

jvican mentioned this pull request Nov 9, 2017

Replace slow SHA-1 by xxHash for classpath hashes #371

Closed

jvican force-pushed the issue-433 branch from 8f58669 to a891062 Compare November 9, 2017 15:55

jvican added performance regression Scala Center labels Nov 9, 2017

fommil reviewed Nov 9, 2017

View reviewed changes

jvican force-pushed the issue-433 branch 2 times, most recently from e7db2f9 to 17d451b Compare November 9, 2017 16:57

leonardehrenfried reviewed Nov 9, 2017

View reviewed changes

jvican force-pushed the issue-433 branch from 17d451b to 1297263 Compare November 9, 2017 17:07

fommil reviewed Nov 9, 2017

View reviewed changes

jvican force-pushed the issue-433 branch from 1297263 to 07aa2c9 Compare November 9, 2017 17:25

jvican removed the in progress label Nov 9, 2017

jvican assigned eed3si9n and Duhemm Nov 9, 2017

fommil approved these changes Nov 9, 2017

View reviewed changes

stuhood approved these changes Nov 9, 2017

View reviewed changes

jvican unassigned eed3si9n and Duhemm Nov 9, 2017

jvican requested review from eed3si9n and Duhemm November 9, 2017 18:32

jvican force-pushed the issue-433 branch from 07aa2c9 to a90a0e9 Compare November 10, 2017 20:48

stuhood approved these changes Nov 11, 2017

View reviewed changes

leonardehrenfried mentioned this pull request Nov 12, 2017

Meta: Performance benchmarks for sbt sbt/sbt#3731

Open

eed3si9n approved these changes Nov 13, 2017

View reviewed changes

Duhemm approved these changes Nov 14, 2017

View reviewed changes

Duhemm merged commit 5dcf3e6 into sbt:1.0.x Nov 14, 2017

dwijnand mentioned this pull request Nov 22, 2017

Merge 1.0.x into 1.x #455

Merged

jvican mentioned this pull request Feb 13, 2018

Cache classloaders for compiler plugins and macros scala/scala#6314

Merged

stuhood mentioned this pull request May 8, 2018

Switch to zinc's built-in fingerprinting pantsbuild/pants#4754

Closed

eed3si9n mentioned this pull request Jan 3, 2020

Hashing vs timestamp sbt/sbt#5348

Open

Fix #433: Make classpath hashing more lightweight #452

Fix #433: Make classpath hashing more lightweight #452

Conversation

jvican commented Nov 9, 2017 • edited Loading

fommil commented Nov 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jvican commented Nov 9, 2017 • edited Loading

fommil commented Nov 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fommil Nov 9, 2017 • edited Loading

Choose a reason for hiding this comment

jvican Nov 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stuhood left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fommil commented Nov 9, 2017

jvican commented Nov 9, 2017

jvican commented Nov 9, 2017

fommil commented Nov 9, 2017

jvican commented Nov 9, 2017

godenji commented Nov 11, 2017

jvican commented Nov 11, 2017

godenji commented Nov 11, 2017

jvican commented Nov 12, 2017

godenji commented Nov 12, 2017

jvican commented Nov 13, 2017

jvican commented Nov 13, 2017

eed3si9n left a comment

Choose a reason for hiding this comment

Duhemm left a comment

Choose a reason for hiding this comment

typesafe-tools commented Nov 25, 2017

jvican commented Nov 9, 2017 •

edited

Loading

jvican commented Nov 9, 2017 •

edited

Loading

fommil Nov 9, 2017 •

edited

Loading

jvican Nov 9, 2017 •

edited

Loading