그래서 0__의 의견은 오른쪽에 있습니다 :
당신이
Readme을 읽게한다.
cacheUnzip
및
cacheOutput
설정을 변경할 수 있다고 제안합니다. 나는 그것을 시도 할 것이다.
cacheUnzip
은 cacheOutput
이 아닙니다. cacheOutput
의 목적은 소스가 변경되지 않은 경우 동일한 항아리를 얻는 것입니다. 일부 사람들에게는 출력 항아리가 불필요하게 변경되지 않는 것이 중요합니다. 주의 사항은 모든 * .class 파일의 SHA-1 해시를 검사한다는 것입니다. 함께 클래스 많은 수의 파일이있는 경우
가
,이 압축 해제 및 병합 전략의 응용 프로그램, 내가 말할 수있는 건 시간이 오래
을 할 수있는 분 주위에 걸립니다 : 그래서 추가 정보는 말한다 또는 2,하지만 SHA - 1의 검사는 영원히 걸릴 것으로 보인다.
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 초에 나섭니다 : 여기 assembly.sbt
출력 캐시를 해제하는입니다. 실행의 일부가 200+ 초도 걸렸지 만.
소스를 살펴보면 cacheOutput
을 최적화 할 수 있지만 지금은 끄면 어셈블리가 훨씬 빨라집니다.
편집 :
나는이 질문을 기반으로 #96 Performance degradation when adding library dependencies을 추가하고, SBT 0.13에 대한 sbt-assembly 0.10.1에 몇 가지 수정 사항을 추가했습니다.
sbt-assembly 0.10.1은 종속 라이브러리 jar의 압축 해제 된 항목에 대한 해싱을 방지합니다. 또한 sbt-assembly가 이미 출력을 캐싱하기 때문에 sbt가 수행 한 jar 캐싱을 건너 뜁니다.
변경 사항으로 인해 어셈블리 작업이보다 일관되게 실행됩니다. deps-heavy spark를 샘플 프로젝트로 사용하여 작은 소스 변경 후 어셈블리 작업이 15 번 실행되었습니다. sbt- 어셈블리 0.10.0은 19 +/- 157 초 (대부분 20 초 이내, 실행 시간의 150 % 이상은 26 %). 반면에 sbt-assembly 0.10.1은 16 +/- 1 초가 걸렸습니다.
[Readme] (https://github.com/sbt/sbt-assembly)를 읽었습니까? 특히'cacheUnzip'과'cacheOutput' 설정을 변경할 수 있다고 제안합니다. 나는 그것을 시도 할 것이다. –
@ 0__ 읽었지만 모든 최적화 옵션이 기본적으로 설정되어있는 것으로 보입니다 – darkjh
예,하지만 이는 _options_입니다. 차이를 만드는 지 알아보기 위해 각각의 캐싱 옵션을 바꿔 볼 필요가 있습니다. –