Comment by xxs | Hacker News Reader

Comment by xxs | Hacker News Reader

Parent Full thread

>and to reduce warmup time to peak JIT performance.

This actually works in the opposite way - JIT is a guided compilation which uses the input for best results. There are many optimizations done for multi call sites, e.g. static linking + guard, dual site inline, inline caches, and the v-table calls if all fails. Without guided optimization such decisions are not likely to happen.

In other words for peak runtime performance JIT would surpass ahead of time/native compilation.

>reduce container size

I would be exceptionally hard pressed to find a single case where that would matter (aside specific client deployments) - server side and the like I'd not care about extra 100MB or so deployable. E.g. if I want really small footprint I'd go and do it all in pure C w/ an absolute min external library support.

>startup times

I already mentioned it - and anything not sub 0.5sec, Java does quite ok. There is a lot to be said about the use of DI frameworks with blatant class path scans, but that's not necessarily Java's fault.

Peak runtime performance is slightly better on JVM, yes. Native Image ships a JIT within your binary so it is not as different as one might think.

my understanding is that native compile isn't shipping a jit, but is running the jitted code that was produced during compilation. However, if your code is so "dynamic" (aka, has lots of deeply nested inheritance) that it slows down procedure calls from so many levels of indirection, then a JVM runtime will jit a better version of native code when running using runtime information (such as jump directly to the correct virtual function instead of indirection). The compiled version do not have access to this runtime information, so you can't get this sort of optimization.

However, for "simple" code (like arithmetic, or manipulation of bits, arrays etc), i think it's pretty much the same.

> There is a lot to be said about the use of DI frameworks with blatant class path scans, but that's not necessarily Java's fault.

I used to support Atlassian's products on the intranet before we migrated (almost) everything on their cloud: Jira, Bitbucket, Bamboo, Confluence. I think Jira and Bitbucket were hands down the slowest of the bunch to boot and from what I could tell it was exactly due to classpath-scanning and god knows what else. I could never believe a 16 CPU 32 GB KVM needs from 3 to sometimes 5 minutes just to boot Jira. To me this was insane.

Reply on news.ycombinator.com