-
Notifications
You must be signed in to change notification settings - Fork 100
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
Maven caplet very slow to launch #101
Comments
I am currently profiling this in an attempt to get a bit more info to add to this ticket. |
From my profiling Aether is taking very little time. Capsule profile output:
Based on profiling:
It appears as if this code is repeatedly reading and parsing the list of entries in the main jar file. I assume it would be relatively easy to cache that info about the jar file, and then simply use that info each time. Ross |
Good job! This is something we can work with. Thanks! |
Hi. I've added caching. Could you test now against master or |
Fixed the launch time issue for me, thanks!
Reduced the launch time from > 17 seconds, to about 1.2 seconds for my test application. Thanks. |
You did all the hard work. |
https://groups.google.com/forum/?hl=en-GB#!topic/capsule-user/oqVIPAPzZW4
My system contains a number of different Java applications (approx 20), each of which uses a large number of jar files (> 100 jars). I have been converting the applications from Docker to Capsule in an attempt to reduce the bloat (it takes a long time to transfer multiple large Docker images across a slow network).
Using the fat capsule results in capsule jars of approx 100M each.
Using Maven capsule seemed like the ideal solution to reduce the size, but results in a very slow launch (15 - 30 seconds), even when running in offline mode after having downloaded all jars (-Dcapsule.offline=true).
I have not analysed it in detail, but it seems to be spending a lot of time in the Aether maven dependency management library.
I have configured the capsule dependencies so that all jars are explicitly listed and don't fetch transitive dependencies e.g. org.slf4j:slf4j-api:1.7.12(:)
Ross
The text was updated successfully, but these errors were encountered: