4 ms·

>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 g

• forty 2y ago
  > still get gapped by statically compiled languages. Which statically complicated languages are you referring to? :)
• pragmatick 2y ago
  Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.
  • sgammon 2y ago
    More of this configuration is automatic with every release
• gf000 2y ago
  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?
• roncesvalles 2y ago
  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.
  • sgammon 2y ago
    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