Timeline for Why is Java AOT compilation (using graalvm native-image) so much slower than golang compilation?
Current License: CC BY-SA 4.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 27, 2022 at 12:06 | comment | added | Laiv | A hint that makes this obvious is the minimum heap required by one framework and the other. While I have been able to compile Quarkus's demo with less than 6GB (in a reasonable time), I have not been able to do so with Spring Boot, which minimum heap (in my case) could not be less than 8GB. Well, it can be, but I have never seen the compilation finish. | |
Jun 27, 2022 at 12:00 | comment | added | Laiv | you can test Jorg last two conclusions by trying the very same you did with quarkus but with Spring Boot. Quarkus has been designed to be a lot more lighter (in terms of dependency graph) than Spring and their code has been properly configured (via metadata) to speed up the compilation to native. Something Spring didn't and it struggles with. Add to this equation transitive dependencies than will never provide the metadata required to ease the compilation or change its design to make it portable... Spring has a hell out of transitive dependencies that leads to more transitive dependencies. | |
Jun 27, 2022 at 1:59 | comment | added | vancan1ty | Thank you for sharing your knowledge. Re "you are compiling a lot more code in your Java example", makes me wonder how hard it would be to precompile a set of dependencies for my java application and just have the native-image step newly compile my application code every time... "native jars"... It's probably overkill as java does have the bytecode compiler to fall back to for development/testing but I will look into it. | |
Jun 27, 2022 at 1:17 | vote | accept | vancan1ty | ||
Jun 26, 2022 at 23:20 | history | answered | Jörg W Mittag | CC BY-SA 4.0 |