-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
packaging takes very long time #68
Comments
I can't work on this issue without having exact reproduction steps and a full log. Do some projects take longer time than the others? Could it be dependent on the library that you are using? The last portion of the log indicates that multiple jars include |
It's intermittent, sometime it stucks forever. full stack trace
sbt version : 0.12.2 Let me know if you want me to monitor on system during process. I monitored memory almost 600mb was free, cpu was 97% idle. |
Have you tried running |
Caching feature was requested in #59 and was added to the latest 0.8.5. This calculates SHA-1 of every single *.class file prior to packaging. Trying running |
I have the same issue with SBT Assembly 0.8.5, Scala 2.9.2 and SBT 0.12.2. Here is my jstack output: https://gist.github.com/4707228 |
As I said it's intermittent, it doesn't happen always. Here are few jstacks when it happened last time. |
Same here! and I dont know if it finish soon! jstack: https://gist.github.com/amrnt/82a716d70b9e1919bbcd I'm on Macbook Air 4GB - Scala 2.10.0 |
It seems like most of your jstacks outputs are in some phase of calculating the hash, which is consistent with my theory that this was introduces as part of #59. I could add a setting to enable/disable caching behavior and turn it off by default. |
After I updated my sbt from 0.12.0 to 0.12.2 It works fine! |
Really? @pankajmi Could you please try sbt 0.12.2, and see if the situation changes for you too? |
0.8.6 is out with default caching turned off. |
I was having problem with 0.12.2, as I mentioned above. |
I tried sbt-assembly version 0.8.6 with sbt 0.12.2. , see time taken below -
Still taking time, and jstack is as follows - |
That's less than half the time as your original report 724 s, and the jstack shows that it's actually making jar instead of doing hash. Creating assembly takes time because we are unzipping all jars and zipping them back again. If you want to avoid that you could take a look at https://github.com/sbt/sbt-onejar. |
@eed3si9n :Thanks for reply, actually I tried sbt-onejar just to check the size of jar that gets generated and surprised to see it generates even smaller jar though it simply puts all in one jar without unzipping. Can you please tell me what other advantages we can get from sbt-assembly apart from assuming it is going to generate one small jar after all merge and all ? I actually thought sbt-assembly should generate smaller. |
sbt-assembly is simpler. see sbt-onejar's page for the comparison. |
I found sbt-assembly takes much longer to compile than one-jar but it is much faster to execute the jar once compiled. As an example, one of my one-jar application takes nearly 30seconds to launch where the same sbt-assembly version is almost immediate. I am assuming the difference is the class clashing is determined at compile time with sbt-assembly and with one-jar the specialized class loader is occurring at run-time. |
@aradke this is an interesting observation. Here's another speculation why onejar would be slower: You can access entries of a zip file without extracting the whole archive. However, you can not access entries of a zip file which lies inside another zip file without extracting the inner zip file. So, to find a class (at least the first) with the one-jar approach the JVM has to extract all of the dependency jars once to find out where the class lies and then load it. Still, 30 seconds sounds very slow. |
Just released 0.9.0 incorporating the pull req #83. This caches the jar unzipping results and cuts down the assembly time for second run onwards: http://notes.implicit.ly/post/51259892611/sbt-assembly-0-9-0 |
Using sbt-assembly 0.9.0, sbt 0.12.3 and scala 2.10, I generate a single 76M jar file in 1612 seconds! Is there a way to cut assembly time further? |
@gip is that for the first run or the second? caching should improve the performance for the second run forward. |
Just released 0.10.1 with some more performance improvements (#96) that should make the run time more consistent: http://notes.implicit.ly/post/65751699253/sbt-assembly-0-10-1 |
I'm seeing this issue on Ubuntu (run within VirtualBox on OS X). Assembly typically takes 10+ mins, or just crashes the whole machine. When I run it from with OS X however, compile time is < 30 seconds. It always hangs whilst/or just after including dependencies. Each include seems to take slightly longer than the one before it. Running SBT 0.13.5, Scala 2.10.3 and SBT Assembly 0.11.2. Not a killer, but odd! |
@joeroot I have the same issue of |
That's probably because disk i/o is more expensive inside a VM (those files need to be read in order to determine their SHA1 hashes) |
One idea that was suggested by @jsuereth was that sbt-assembly try reading into the JAR directly without unzipping first. ymmv/pr welcome on this front. |
If you're using |
@eed3si9n I have the exact same problem; my project is barebones, spark, akka, scala 2.11.8 - was there an option to disable calculation of SHA1 that was added? Assembly is taking 774+ seconds
This is my assembly sbt -
Not sure how to make it fast but it is affecting my development timelines - any help, suggestions, rants are welcome... |
@AnirudhVyas are you building in a VM? |
no - build on macbook os x |
@AnirudhVyas Do you have SSD drive on your MacBook? |
I have an ssd, let me see thanks. Will report back... |
not much difference - well I gained about 100 seconds if thats a consolation ... do you know where the bottleneck is? it seems to be taking a while in packaging... Honestly I have been using this awesome plugin for a while, but I never used it with spark, I used to tar up, thought I'd give it a try while putting it along with sbt on a fresh project - something is missing ... |
ok for now I made my app a spark submit - i was using a single package for a reason, with provided spark dependencies, less things to deal with, it completes in 180s ... very doable i think. But it would be great if know where the bottleneck was/is so that perhaps it could be improved? I am not implying that you haven't tried already - my apologies if I come across as blunt... |
I personally haven't run into performance issues so I haven't really looked at current bottlenecks. If there's some specific issue around, feel free to create a sample project that someone could look into. |
I've played a bit with sbt-assembly 0.14.7-SNAPSHOT. My fat jar is about 130 MiB. My computer has SSD. Could anyone test this solution on own project?
|
@eed3si9n Fat jar size is 96 MiB. UPD: on HDD it works much faster, less than 60 seconds. |
I guess creating >60k files while unpacking puts major stress on the file system. Doing that non-sequentially by adding |
hello from 2019. I had this exact problem (yes,old project old version of sbt, but still) and doing YMMV |
I'm on |
any updates on this thread it's hanging for long time in the ubuntu 18.04 LTS @karthicks @noahlz @devmanhinton ? |
Wowwow found my way back to this issue via google. I have no insight except trying what past me did (clean assembly) |
I am not sure if I am the only one who is facing this problem but
Packaging takes hell lot of time. May be I am missing some settings or something.
Last these three steps are the slowest, build stucks here for long long time.
Please let me know if anyone need more info ?
The text was updated successfully, but these errors were encountered: