sbt-assembly icon indicating copy to clipboard operation
sbt-assembly copied to clipboard

sbt Clean & assembly step sometime takes very long time

Open Diliprajgor opened this issue 4 years ago • 6 comments

steps

sbt clean compile assembly takes very long time

problem

sometimes clean itself takes ~1218s but some times rungs very fast but the assembly step is always takes at least 45 mins to complete. i am using sbt 1.2.8 open jdk 8 with hotspot 64 bit in windows 10

image

image

the build.sbt has the below assemblyOption too

assemblyOption in assembly := (assemblyOption in assembly).value.copy(cacheOutput = false) ```


# content of sbtconfig.txt
```# Set the java args to high

-Xmx1G

-XX:MaxPermSize=512m

-XX:ReservedCodeCacheSize=512m



# Set the extra SBT options

-Dsbt.log.format=true
-Dsbt.task.timings=true

Diliprajgor avatar Feb 26 '21 18:02 Diliprajgor

If this is mostly about sbt-assembly, let's move this to sbt/sbt-assembly.

eed3si9n avatar Feb 26 '21 20:02 eed3si9n

It's very slow for me on the Windows drive in WSL2. A native checkout in WSL2 is very quick to assemble.

frankivo avatar Apr 20 '21 13:04 frankivo

The problem is whenever a disk is involved, be it WSL1 or WSL2 or an old Hard drive with a spinning motor, the performance of the assembly is very much affected, due to its IO-Heavy strategy of unzipping files to disk. The problem is least-noticeable when I run the asembly on an SSD drive or even a Gen 4 NVME drive.

To put it in perspective, assembling the same project after a clean: WSL1 in the office using an SSD: anywhere from 10 to 30 minutes! NVME gen 4 drive (7000MB read/write) at home, using WSL2: 21 seconds!

I don't have the in-between numbers, i.e. native SSD, native spinning drive, WSL spinning drive, network drive, etc.

To cater for the general usage we should definitely refactor the assembly.

I am looking into this issue. My goal is to minimize disk usage as much as possible and rely more on in-memory buffering.

EDIT: For context, the assembly JAR size is around 80MB

fnqista avatar Mar 29 '22 21:03 fnqista

Please try 2.0.0-RC1 and provide feedback

fnqista avatar May 10 '22 12:05 fnqista

I have been using v0.15.0 on a bunch of projects. recently had a project where I cleared the cache and then it would try to build for 20 minutes+ which was much longer than our usual assembly time (7-10 minutes). It got to the point where my Macbook pro would grind to a halt. Saw this issue and upgrade to 2.0.0-RC1 the project that wouldn't build was built from clean in about a minute with subsequent builds in ~30s. Ran it and everything appears in worked order so these updates definitely resolved a related issue I was having and overall is a dramatic improvement for our projects

kevin-brendle-lark avatar Jun 03 '22 16:06 kevin-brendle-lark

+1 on latest build for those that are having slowdown with sbt clean assembly, version 1.X.X was taking 9 minutes. Bumped to 2.1.5, build finished in 21 seconds - incredible!

mdrakiburrahman avatar Nov 25 '23 14:11 mdrakiburrahman