所以0__的评论是正确的:
你读过自述文件吗?它特别建议您可以更改cacheUnzip
和cacheOutput
设置。我会试一试。
cacheUnzip
是一项优化功能,但cacheOutput
不是。的目的cacheOutput
是让您在源未更改时获得相同的 jar。对于某些人来说,重要的是输出 jar 不会进行不必要的更改。需要注意的是,它正在检查所有 *.class 文件的 SHA-1 哈希。所以自述文件说:
如果有大量的类文件,这可能需要很长时间
据我所知,解压缩和合并策略的应用大约需要一两分钟,但检查 SHA-1 似乎需要很长时间。这是assembly.sbt
关闭输出缓存的:
import AssemblyKeys._ // put this at the top of the file
assemblySettings
mergeStrategy in assembly <<= (mergeStrategy in assembly) { (old) => {
case PathList("javax", "servlet", xs @ _*) => MergeStrategy.first
case PathList("org", "apache", "commons", xs @ _*) => MergeStrategy.first // commons-beanutils-core-1.8.0.jar vs commons-beanutils-1.7.0.jar
case PathList("com", "esotericsoftware", "minlog", xs @ _*) => MergeStrategy.first // kryo-2.21.jar vs minlog-1.2.jar
case "about.html" => MergeStrategy.rename
case x => old(x)
}
}
assemblyCacheOutput in assembly := false
清洗后组装在 58 秒内完成,第二次不清洗则用时 15 秒。虽然有些跑步也花了 200 多秒。
查看源代码,我可能可以优化cacheOutput
,但就目前而言,关闭它应该会使组装速度更快。
编辑:
我在添加基于此问题的库依赖项时添加了 #96 性能下降,并在sbt-assembly 0.10.1中为 sbt 0.13 添加了一些修复。
sbt-assembly 0.10.1 避免了依赖库 jar 的解压缩项目的内容散列。它还跳过了 sbt 完成的 jar 缓存,因为 sbt-assembly 已经在缓存输出。
这些更改使装配任务运行更加一致。使用 deps-heavy spark 作为示例项目,在进行小的源代码更改后,组装任务运行了 15 次。sbt-assembly 0.10.0 耗时 19+/-157 秒(大部分在 20 秒内,但 26% 的运行时间超过 150 秒)。另一方面,sbt-assembly 0.10.1 耗时 16+/-1 秒。