If you're not calling your code 5000x then it's likely not important for performance. I worked in compilers for 5 years and people's intuition for what parts of the code are the bottleneck is generally not very good. This includes me, I've guessed wrong a WHOLE lot.

If you're running microbenchmarks and having issues, then you're likely not using JMH, the Java Microbenchmark Harness which used to be a 3rd party library but is now built in to Java 12.

Is Java memory hungry? Maybe. If you're just writing a small routing server, probably not the right use case for Java. If you're writing a big and complicated game server with hundreds of routes and you need to talk to MySQL, Redis, and Memcache then I'd say the memory overhead of Java is really quite good. Don't forget that you can tune the min/max heap and other things like that, especially with the module system in Java 11. However if very low memory is a requirement, then you're probably running in an embedded environment and you probably shouldn't be using Java.

> If you're just writing a small routing server, probably not the right use case for Java.

General purpose languages have "use-cases"?

Yes, I wouldn't use Haskell for scripting and I wouldn't use javascript for a 3D game engine.

I think in this context Java means "the platform" i.e. the JDK

the usual C2 kicks-in is 10000, not 5k. But that statement about warming up is true only for microbenchmarks.

C1 which is an dumb (but not terrible) compiler tends to be at 1k, and if you cannot get your code to 1k, likely it never needs compilation, so no point to spend time and space on performing the said compilation.

The 'prewarming' does include perf. counters, so it's guided compilation to boot.

What?

I suspect that the parent is talking about the JVM's JIT, where it compiles java bytecode into machine instructions after loading the application. This is why the first few requests on a JVM are usually considerably slower than the rest.

Parent is obviously exaggerating with the 5000x, and he could have made his point in a different way, but there's some truth to it.

5000 refers to number of times a method needs to be called before the JIT decides the method is "warm" and needs to be compiled by the expensive to run C2 compiler which produces good quality machine code.

If you're benchmarking java code and the method was not called enough times before you measure, you're measuring code compiled by C1 (or even interpreted).

The performance gap between Java and C is on the order of x2 to x5.

Why not just pass -Xcomp? From the docs[1]: "You can completely disable interpretation of Java methods before compilation by specifying the -Xcomp option."

[1] https://docs.oracle.com/javase/8/docs/technotes/tools/window...

At the same time, JIT can outperform native code in some specific circumstances, since there are certain optimizations which can be proven safe at runtime which can not be guaranteed to be safe at compile time

this is a thing people say a lot but it is not something that seems to often result in an actual java program or benchmark being faster than program compiled AOT by an equivalently smart compiler (llvm etc)

Actually one of the less known features of the JIT is the ability to deoptimize/recompile based on CHA (class hierarchy analysis) or pushed compilation request via invokeDynamic&friends.