It has been shown to run faster in some benchmarks. This is usually due to hotspot optimizations performed at runtime by the VM, but also sometimes thanks to offloading the (often costly) deallocation of memory from the main thread. Since Java has a GC running in a background thread, the deallocation of memory occurs outside of the measured execution.
However, I remain convinced that while burst execution of a computation can perform on par with a language like C or Rust, the total resource usage of Java code is significantly worse. When taking into account the entire execution including GC and JIT compilation, it will have spent more memory and/or CPU cycles. It’s harder to quantify, but the overall performance experienced by the user becomes worse. Fans run more and battery time is lower.
It has been shown to run faster in some benchmarks. This is usually due to hotspot optimizations performed at runtime by the VM, but also sometimes thanks to offloading the (often costly) deallocation of memory from the main thread. Since Java has a GC running in a background thread, the deallocation of memory occurs outside of the measured execution.
However, I remain convinced that while burst execution of a computation can perform on par with a language like C or Rust, the total resource usage of Java code is significantly worse. When taking into account the entire execution including GC and JIT compilation, it will have spent more memory and/or CPU cycles. It’s harder to quantify, but the overall performance experienced by the user becomes worse. Fans run more and battery time is lower.