Skip to content
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

Reduce size of output executable #287

Open
ianopolous opened this issue Jan 20, 2018 · 8 comments

Comments

@ianopolous
Copy link

commented Jan 20, 2018

Compiling hello world with substrate vm on ubuntu results in a 6.1 MiB executable. Is it possible to reduce this? The equivalent in golang is 1.6 MiB or < 1 MiB without debug information.

@vjovanov vjovanov self-assigned this Jan 25, 2018

@vjovanov

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2018

True, I have evaluated the image size and even for an empty main program we get ~5MB of an image. There are a few reasons for that:

  1. In our features we use JDK code that has non-negligable footprint. To see all kinds of things that get pulled in you can add -H:+PrintUniverse to the image build.
  2. Some of our features are included into the image although they are never used in the code.
  3. The points-to analysis is imprecise and sometimes catches elements that are never used.

On the bright side, if you include much of your code the 5MB overhead will remain the same. So this is an issue only for very small images.
This is a great issue. If you have a need for small images in your use-case, please mention it here and we will raise the priority.

@vjovanov

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2018

unused-pkgs-hw.txt
unused-classes-hw.txt
unused-methods-hw.txt

These are the packages, classes, and methods that are never invoked. They can use as an indicator for elements that should not be in the image. Some things like the heap package must be included into the image, although for this particular program they are never used.

@pejovica thanks for the data.

@ianopolous

This comment has been minimized.

Copy link
Author

commented Jan 30, 2018

The general use-case is to remove a common argument for people to use Go-lang. One specific use-case that this would severely impact is something like implementing many small command line utilities as in Linux.

Does that 5 MiB include the GC? At least for simple things like helloworld you can prove you don't need a GC.

@vjovanov

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2018

It does, but by looking at the list of included elements, I would not say that GC is the biggest problem. I would rather invest that time to remove things that should not be there by any means. For example, org.graalvm.compiler.truffle, java.util.zip, java.util.regex, java.util.Calendar.

By removing these I am confident that we can reach the size of the GOs "Hello, Word!". At one point we removed all methods that were never executed and the image size was 400 KB. This is the lower bound of course, but could be used as a guideline of what we should reach.

@ianopolous

This comment has been minimized.

Copy link
Author

commented Jan 30, 2018

Thanks @vjovanov, that would be amazing!

@CremboC

This comment has been minimized.

Copy link

commented Apr 30, 2018

You can also use https://upx.github.io/ as a temporary solution to make compressed binaries. Reduces the size by a lot in my experience.

@miere

This comment has been minimized.

Copy link

commented Apr 11, 2019

Any thoughts on this, guys?

I'm targeting Graalvm as the (probably/hopefully) the solution for the long cold-starts in AWS Lambda functions written in Java. Smaller binaries would make our deployments faster. Also, AWS has some limits on deployment size, I'm afraid that binaries would become too big if we have multiple dependencies in our project - which is usually the case when using AWS SDK.

I think that's a game changer functionality that would make JVM more attractive to the community, especially those who have been flirting with Go and Rust as an alternative.

@SchulteMarkus

This comment has been minimized.

Copy link

commented Apr 11, 2019

(not issue relevant) @miere , already discovered https://quad.team/blog/Micronaut-to-AWS-Lamda-guide ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.