Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by Yasuraka | Hacker News Reader

Parent Full thread

Yasuraka·

>I'd much rather a hotspot VM analyze the running code

wasting gigabytes of ram and fast startup times

>and identify the optimizations on the fly

and still get gapped by statically compiled languages.

I guess these are a cheap price to pay for the benefit of ... having to install and patch runtimes.

View on HN

Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.

More of this configuration is automatic with every release

There are instances where JVM's dynamically optimized code runs faster than equivalent C code compiled to a native binary. The Hotspot JVM is no joke.

It's not either/or. Compiling a Native Image binary gives you the JIT power of the JVM, but with faster warmup time.

Peak-peak performance is not as good as JVM in many cases, but how long does your process actually spend within that space? Native Image can be optimal for many cases

> still get gapped by statically compiled languages.

Which statically complicated languages are you referring to? :)

Unused RAM is wasted. If you have plenty available then doing useless memory releases (including dropping/destroying objects with RAII, which can end up doing a lot of work in case of a data structure containing other objects that have to be dropped) will just hurt your throughput. Nonetheless, Java has a pretty trivial single flag to set an appropriate heap size if you are not happy with the default.

You are thinking of AOT compiled, but does that AOT language support arbitrary class loading to expand functionality, live observability while taking almost zero overhead for that?

So what do you do if a statically linked library of yours has a vulnerability?

Reply on news.ycombinator.com