Hacker News Reader

Comment by pegasus | Hacker News Reader

Seriously? Since 2011, so since Java 7, stagnation in performance? That's a startling claim. I'd like to see some numbers as well. I'll start the first round with this article:

https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html

Note: this is comparing to Java 17 to Java 8 (released in 2014), and we are now at Java 24!

View on HN

That is garbage collection performance, something that only GC languages even have to consider as additional overhead. It also doesn't even try to compare against anything non-Java.

There are no serious Java performance comparisons on stuff like transaction throughput, which would be what the "long running server application" usecase should aim for. You yourself claimed that enterprise data processing is what you are talking about. There are benchmarks that even with long warmup times make Java come up far worse than all the compiled languages (even Golang nowadays). https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Imho, people have stopped benchmarking Java ages ago, since it is known to be hopeless.

I think you need to say what you mean by "far worse".

If you look at the extremes, it is up to a factor of 3: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

If you exclude stuff like SSE intrinics, it's usually 50% slower.

To be clear, you're saying for the benchmark tasks with the worst performing Java programs; the Java programs perform worse than the Go programs for the benchmark tasks with the worst performing Go programs?

What about the median performance benchmark tasks?

I'm saying that Golang is one of the worst-performing compiled languages, and even Golang is faster than Java for the respectively fastest program on the page I've referenced. Other compiled languages are even better than Golang.

The Java programs median shows slightly faster than the Go programs median, in the first chart on that page.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Calling GC time "additional overhead" is not entirely correct, imo. Non-GC languages often spend plenty of time dealing with malloc/free, and I consider both GC and malloc/free to be "memory management". Both are non-trivial!

GC usually also comes in "copying" variants, which can have advantages like reducing memory fragmentation.

Granted, malloc/free isn't totally free. But malloc/free languages always seem to be faster than Java in benchmarks, at least the ones I've read and referenced already in the comments around this article. GC also, even if it were faster, comes at the expense of eating RAM like mad, at least if judged by the RAM Java likes to eat. Usually, Java software just consumes 50% of your RAM until the first GC pause. And even before that GC pause, it's dog slow.

Memory fragmentation can more easily be reduced by pooled allocators. For long-running server processes, it can also be possible to just kill the worker processes/threads from time to time. And I've never seen memory fragmentation in manually allocated languages lead to more memory consumption or worse performance than in Java.

https://www.techempower.com/benchmarks/#section=data-r23&tes...

Here is your transaction throughput. But I'm sure AWS's whole platform team, Alibaba, third of Google, etc don't know what they are doing.

No big difference for stuff that waits for I/O, at least if it doesn't do it in an inefficient way. No Java in sight in the top lot for "Cached queries" which is the one where language makes a difference.

Reply on news.ycombinator.com