Has anyone done an analysis on why despite Java having such a head start with tech like JIT, it [appears] to have worse perf than JS?
Conversation
Replying to
From what I recall of Java, the JIT and GC are highly configurable and even entirely different implementations can be swapped in/out. So, perhaps with no adjustments JS might outperform in certain cases.
1
1
Replying to
Then why did/does java pick such terrible defaults? Why does java have such a terrible runtime for a simple hello world program?
2
Replying to
These are all good questions. I'd say that lack of sane defaults overall is why I don't like Java anymore. It's definitely not designed to rock the simple hello world cli out of the box. The last CLI I worked with would take 100's of ms from vm launch to hit my code.
1
1
1
Replying to
Other question, why doesn't the defaults change over time? Like oh, we've run for more than 20 seconds, lets switch our defaults from client to server defaults, or something like that.
1
Replying to
This might be a good question for someone with Java VM implementation expertise. /cc sorry to cross-link you into the conversation, but I thought you might find it interesting.
1
1
At least in my brief testing, being able to switch this would be great:
Quote Tweet
Replying to @laffer1 and @seeteegee
I did manage to find: stackoverflow.com/questions/1491
But the only thing that made a big difference was: `-XX:TieredStopAtLevel=1`.
It dropped overall runtime (signal-cli --help) from ~.95s to ~.86s, but the big drop was user time, from 1.7s to .85s.
Still pretty terrible perf.
1
Java has historically tuned the runtime for long running server processes. It won't typically win a "helloworld" competition but will blow must other runtimes out of the water comparing peak performance.
"helloworld" is fine for blog posts but what's your actual workload?
2
2
Problem is when you're doing dev, running tests, etc., that startup perf really grinds you down. (That assumes you could even get it for your platform.). In my immediate case it's sending a simple signal (im) message.
3
1
Build it into a native executable with the full standalone GraalVM instead of using JIT compilation with OpenJDK. OpenJDK isn't the only way to run Java and isn't at all efficient for short-lived processes. The JIT compiler is probably hurting you more than helping for this.
JavaScript implementations lean much more heavily on a fast baseline interpreter. In fact running Chromium with --jitless tends to only have 5-10% performance overhead for typical non-compute-heavy web applications. Still has built-ins, interpreter, etc. as optimized native code.
1
1
OpenJDK is only really optimized for long-lived processes no matter how you configure it.
Android's Kotlin/Java implementation (ART) only really uses JIT to bootstrap AOT. It starts with interpreter/JIT and gradually moves to everything being AOT compiled guided by JIT profiles.
1
1
There was jaotc from OpenJDK 9 through OpenJDK 16 but it wasn't as good and they removed the port of the Graal JIT / AOT compiler in 17. Maybe that was available for FreeBSD? It seems Graal is portable to FreeBSD in general because github.com/oracle/graaljs appears to support it.
