Curious what folks are getting for the native app size?

[kenyee]

I thought I had a fairly trivial app and it generated a 137MB app for me 😮

It does use reactive resteasy and panache and hibernate and oidc and openapi, so it's a fairly typical microservice....

Is there a list of native app size binary blob sizes for each extension? Curious how big each of the things I added contributes to the binary size...

[gsmet]

If you can prepare a reproducer I would be curious to have a look at it.

[kenyee]

Same project mentioned in this thread: #23181
Delete the import.sql file
Then run "./gradlew build -Dquarkus.package.type=native"

And

ls -l build
total 266984
drwxr-xr-x  5 keny  staff        160 Jan 27 13:26 bugquarkusjpatest-1.0.0-SNAPSHOT-native-image-source-jar
-rwxr-xr-x  1 keny  staff  136689616 Jan 27 13:26 bugquarkusjpatest-1.0.0-SNAPSHOT-runner

[kenyee]

Tested removing some artifacts and liquibase was 35MB of the binary 😮
Removing panache/agroal/jdbc-mysql was another 30MB of the binary 😮
Micrometer is 1.5MB
OIDC is 3.6MB
smallrye-health is 1.5MB
OpenAPI is 2.4MB

I'm left with resteasy reactive and Kotlin at about 50MB for the smallest useful native binary for me.
I'm pretty shocked liquibase is bigger than Hibernate/Panache 😂
Will have to rethink whether I should use Liquibase or just let Hibernate handle updates by itself..

[Sanne]

Hi, I just had a look and was about to suggest the same... some extensions are more optimised than others. The Liquibase module in particular is IMO something more useful during development and isn't necessarily something I'd recommend including into the production binary.

When you look at removing individual extensions, it's hard to say - for example - if Micrometer is consuming 1.5MB or if that's rather its impact when combined with the particular other exctensions. GraalVM can be very effective at removing large chunks of dead code, including significant portions of the JDK, but it will only do so when it can safely proof that such code isn't being used by any code in the application at all.

So for example if both OIDC and PosgreSQL use a particular cryptographic cypher "X" which consumes 5MB (just making up an example, but the cyphers are in fact sometimes rather large), you'd only save those 5MB if you removed both OIDC and PosgreSQL. And the same approach works at the finest level, to the symbol.

Many Quarkus extensions include optimisations to help guide the GraalVM compiler into removing such dead code, helping identify specific methods which are dead in one particular application; sometimes such optimisations are missing or more rudimentary, which might lead to situations like the Hibernate ORM extension to be relatively small compared to say Liquibase (I've spent months on the first, but not spent much time at all on Liquibase).

As a general note, remember that while the ~137 MB might seem rather large, it doesn't include just your code but also all libraries and the whole JDK and the JVM. It's not small and we're still improving on that (I just got ~130 MB locally testing your demo but I'm running a development build of GraalVM from today), but hopefully it helps putting things in perspective if you compare it with the whole JVM + app and dependenciesyou'd normally have.

The GraalVM project also offers some additional tooling to help figure out what is consuming space in your binary. Version 22.0 prints some nice reports by default.

[Sanne]

Also, it's worth keeping in mind that only a portion of the whole binary is going to be loaded in memory, and the "disk size" doesn't relate with the actual memory this application is going to require. We prefer to focus on actual resident set memory consumption, as that's what costs more when scaling applications.

• https://quarkus.io/guides/performance-measure#platform-specific-memory-reporting

[kenyee]

Thanks Sanne...that's fair. Was just surprised that I've seen live coding demos and blogs creating native images that are only 40MB and didn't expect mine to be that much bigger :-)
For Liquibase, I've used it for online migration in other projects (so Hibernate's update mode isn't needed)...I didn't expect it to pull so much of it in because I just needed it to run some SQL scripts to do updates and handle a rollback if needed. I expected Hibernate to be much bigger than Liquibase :-)

[Sanne]

Right, now to be fair I haven't seen many demos able to reach 40MB. In my experience a simple app will average about ~70 MB, but the size is determined mostly by the number and the quality of its extensions: your "trivial app" doesn't have much code but it includes several extensions: I wouldn't say that's a lot but it's more than what I normally see, and some of which haven't been optimised much.

Regarding Liquibase: it's of course a better tool than Hibernate when it comes to handle migrations, but I really wouldn't recommend to include "live database migration" capabilities in a native-image optimised application: these are meant to be small, and will likely be run in large numbers to provide elasticity via quick scale up [down]. While a DB migration is something you'd want to be run as a singleton, and only once for each new rollout - I'd expect that to be handled by a custom build of the application which you run only once, and most likely it won't be worth it to compile this one to native, or bother with size optimisations since you're only starting one of these, and possibly for a short time.

In other words, in terms of microservices I'd expect the "schema migrator" to be a separate service, most likely sharing some code.

Your main application could then use the Hibernate ORM's "validate" to ensure everything is fine, or "none" for maximum bootstrap efficiency, if you trust your pipeline. I'd indeed not use Hibernate ORM's "update" as that's meant as a developer convenience for throw-away experiments.