4 ms·

I'd like to see those numbers please. While there have been improvements, Java performance work seems to have stopped after 2011 or so. Mobile CPUs became fast

I'd like to see those numbers please. While there have been improvements, Java performance work seems to have stopped after 2011 or so. Mobile CPUs became fast enough for Android, so no movement there. And commercial software got stuck on numerous proprietary Java VMs that didn't improve after the Oracle takeover of SUN. Alterative VMs improved, but didn't get adopted, fragemented and in the end didn't really raise the bar a lot. To this day, Java applications are the slowest and most memory hungry long-running server applications by far. Only some scripting languages are worse, but only by performance, almost never by memory.

pegasus 1y ago
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 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!
- holowoodman 1y ago
  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/fastest/javavm-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Imho, people have stopped benchmarking Java ages ago, since it is known to be hopeless.
  - igouy 1y ago
    I think you need to say what you mean by "far worse".
    - holowoodman 1y ago
      If you look at the extremes, it is up to a factor of 3: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... If you exclude stuff like SSE intrinics, it's usually 50% slower.
      - igouy 1y ago
        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?
        holowoodman 1y ago
        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.
        igouy 1y ago
        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/download/fastest-elapsed.svg https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - ColonelPhantom 1y ago
    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.
    - holowoodman 1y ago
      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.
  - gf000 1y ago
    https://www.techempower.com/benchmarks/#section=data-r23&test=query 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.
    - holowoodman 1y ago
      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.
hyperpape 1y ago
> While there have been improvements, Java performance work seems to have stopped after 2011 or so. No idea how you got that impression. Here is an incomplete set of important changes: - major developments on Graal and native code compilation for applications that prioritize startup time and memory use (I think Graal was started before 2011, but has changed a huge amount since then). - the concurrent G1 garbage collector became the default, making most applications have much lower pause times (I believe it was released in Java 7 in 2011, but was not mature, only became a default in Java 9, and has regular improvements since then). - the Shenendoah and ZGC concurrent garbage collectors were not started until well after 2011 - project lilliput, which reduces the header size of Java objects from 16 to 8 bytes is landing in Java 25, which comes out this fall - specializing strings to use 1 byte/character for ascii strings, and 2 bytes for non-ascii strings - virtual threads shipped in Java 22 - work on a vectorization API - plenty of work on reducing the startup time of the JDK and modularizing it One where I'm not sure about the timeline: - https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl... class data sharing to lower overhead of running multiple JVMs on a single node P.S. I'm not writing this to comment on the the parent's claim that Java is faster in some contexts.
- holowoodman 1y ago
  The grandparent made specific claims about scenarios where Java is supposedly faster: > Yes, Java can be faster in certain contexts: the kind of contexts Java is usually employed in addressing these days. Stuff like enterprise backend systems and big data processing, where startup time or precise memory control are not important. The only thing that might be relevant in your list is the vectorization API. The rest of your list is just a bunch of band-aids for the worst problems that Java specifically has, that other languages lack. That is at best playing catch-up with everything else, since in C there is no GC overhead, almost no startup time, no object overhead, no GC-induced memory hogging, no GC pauses. Yes, I agree that things did happen. But nothing in there makes Java any more desirable for relevant workloads, it just makes it less undesirable.
  - gf000 1y ago
nu11ptr 1y ago
> To this day, Java applications are the slowest and most memory hungry long-running server applications by far I am not a fan of Java, but the slow part is just plain wrong. On properly sized hardware Java is blisteringly fast. Did it exceed the speed of C as hyped? No, in most cases it falls solidly short, but I'm sure there are isolated cases where it does. Regardless, 2-3x slower than C using a JIT is a serious feat of engineering. All GC languages require more memory, and Java is even worse given lack of value types, but again, memory/hardware is cheap compared to programmer time and if you have enough of it, it generally isn't a problem. All this does mean you will need a bit more hardware than a C program, so perhaps that is the posters critique, and that is true, but compared to other high level languages, it does great in the speed dept, and is often only a bit higher in the memory dept.
gf000 1y ago
What was the core of the hype at the time was parallel processing. And to be honest, here Java absolutely beats C, which most of the time will simply.. refuse to parallelize because it can't be maintainably and reliably done in the language without some very extreme cost. It's simply too dangerous. Meanwhile in Java people could freely experiment with concurrent data structures and algorithms that will simply be in a completely different league than the serial C program. Sure, maybe the latter's hot loop is faster, but it doesn't mean much if I can just run 100s of threads with Java. Your second paragraph is just thoroughly uninformed, though. And unused RAM is useless, so in a server application not making use of it is just dumb. Maybe think about why Java is used extensively by pretty much every FAANG company. Also, Java has improved steadily after Oracle's takeover, and is in fact the open-source reference implementation. Again, uninformed bullshit.
- holowoodman 1y ago
  > Maybe think about why Java is used extensively by pretty much every FAANG company. Java programmers are a dime a dozen. Universities churn out heaps of Java code slaves, so of course every big company will use Java for their shovelware.
  - gf000 1y ago
    There are even more JS and Python devs. Maybe have a go at my other points instead.
peterashford 1y ago
I can only assume that you stopped paying attention in 2011 or so because "slow", Java is not. Memory hungry, sure, I don't think anyone would deny that.

pegasus 1y ago

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

holowoodman 1y ago
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/fastest/javavm-go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Imho, people have stopped benchmarking Java ages ago, since it is known to be hopeless.
- igouy 1y ago
  I think you need to say what you mean by "far worse".
  - holowoodman 1y ago
    If you look at the extremes, it is up to a factor of 3: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... If you exclude stuff like SSE intrinics, it's usually 50% slower.
    - igouy 1y ago
      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?
      - holowoodman 1y ago
        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.
        igouy 1y ago
        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/download/fastest-elapsed.svg https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- ColonelPhantom 1y ago
  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.
  - holowoodman 1y ago
    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.
- gf000 1y ago
  https://www.techempower.com/benchmarks/#section=data-r23&test=query 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.
  - holowoodman 1y ago
    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.

hyperpape 1y ago

> While there have been improvements, Java performance work seems to have stopped after 2011 or so. No idea how you got that impression. Here is an incomplete set of important changes: - major developments on Graal and native code compilation for applications that prioritize startup time and memory use (I think Graal was started before 2011, but has changed a huge amount since then). - the concurrent G1 garbage collector became the default, making most applications have much lower pause times (I believe it was released in Java 7 in 2011, but was not mature, only became a default in Java 9, and has regular improvements since then). - the Shenendoah and ZGC concurrent garbage collectors were not started until well after 2011 - project lilliput, which reduces the header size of Java objects from 16 to 8 bytes is landing in Java 25, which comes out this fall - specializing strings to use 1 byte/character for ascii strings, and 2 bytes for non-ascii strings - virtual threads shipped in Java 22 - work on a vectorization API - plenty of work on reducing the startup time of the JDK and modularizing it One where I'm not sure about the timeline: - https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl... class data sharing to lower overhead of running multiple JVMs on a single node P.S. I'm not writing this to comment on the the parent's claim that Java is faster in some contexts.

holowoodman 1y ago
The grandparent made specific claims about scenarios where Java is supposedly faster: > Yes, Java can be faster in certain contexts: the kind of contexts Java is usually employed in addressing these days. Stuff like enterprise backend systems and big data processing, where startup time or precise memory control are not important. The only thing that might be relevant in your list is the vectorization API. The rest of your list is just a bunch of band-aids for the worst problems that Java specifically has, that other languages lack. That is at best playing catch-up with everything else, since in C there is no GC overhead, almost no startup time, no object overhead, no GC-induced memory hogging, no GC pauses. Yes, I agree that things did happen. But nothing in there makes Java any more desirable for relevant workloads, it just makes it less undesirable.
- gf000 1y ago

nu11ptr 1y ago

> To this day, Java applications are the slowest and most memory hungry long-running server applications by far I am not a fan of Java, but the slow part is just plain wrong. On properly sized hardware Java is blisteringly fast. Did it exceed the speed of C as hyped? No, in most cases it falls solidly short, but I'm sure there are isolated cases where it does. Regardless, 2-3x slower than C using a JIT is a serious feat of engineering. All GC languages require more memory, and Java is even worse given lack of value types, but again, memory/hardware is cheap compared to programmer time and if you have enough of it, it generally isn't a problem. All this does mean you will need a bit more hardware than a C program, so perhaps that is the posters critique, and that is true, but compared to other high level languages, it does great in the speed dept, and is often only a bit higher in the memory dept.

gf000 1y ago

What was the core of the hype at the time was parallel processing. And to be honest, here Java absolutely beats C, which most of the time will simply.. refuse to parallelize because it can't be maintainably and reliably done in the language without some very extreme cost. It's simply too dangerous. Meanwhile in Java people could freely experiment with concurrent data structures and algorithms that will simply be in a completely different league than the serial C program. Sure, maybe the latter's hot loop is faster, but it doesn't mean much if I can just run 100s of threads with Java. Your second paragraph is just thoroughly uninformed, though. And unused RAM is useless, so in a server application not making use of it is just dumb. Maybe think about why Java is used extensively by pretty much every FAANG company. Also, Java has improved steadily after Oracle's takeover, and is in fact the open-source reference implementation. Again, uninformed bullshit.

holowoodman 1y ago
> Maybe think about why Java is used extensively by pretty much every FAANG company. Java programmers are a dime a dozen. Universities churn out heaps of Java code slaves, so of course every big company will use Java for their shovelware.
- gf000 1y ago
  There are even more JS and Python devs. Maybe have a go at my other points instead.

peterashford 1y ago

I can only assume that you stopped paying attention in 2011 or so because "slow", Java is not. Memory hungry, sure, I don't think anyone would deny that.