3 ms·
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM. There's a reason why folks keep com
by Twirrim 16d ago
The slight drawback is that AOT compiled Java code's performance isn't as good as the JIT compiled form running on the JVM.
There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes.
As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for.
If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
- bebop 15d agoFull agreement with everything you said. Just one detail to add on serverless (and potentially in a scheduled environment like k8s), startup time can be an order of magnitude or more faster in a native build. For instance, I have some quarkus applications that can take 10 seconds to ready running via the jre that take 10ms or less to start as a graalvm built binary.
- pjmlp 15d agoDepends on how much effort, like on C and C++, you are willing to put into PGO metadata for the compiler and linker.
- samus 14d agoEven if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.
- pjmlp 14d agoIt works well enough for systems software written in C and C++, where Java still remains a niche option, even when it could deliver.
- samus 13d agoJava has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt as much.
- pjmlp 13d agoDepends on how many dynamic libraries or OOP features get used, or the C++ frameworks inspired by Smalltalk that predated Java by a decade.