| |
| ▲ | nu11ptr 4 days ago | parent | next [-] | | > 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. | |
| ▲ | peterashford 4 days ago | parent | prev | next [-] | | 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. | |
| ▲ | gf000 4 days ago | parent | prev | next [-] | | 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 4 days ago | parent [-] | | > 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 3 days ago | parent [-] | | There are even more JS and Python devs. Maybe have a go at my other points instead. |
|
| |
| ▲ | pegasus 4 days ago | parent | prev | next [-] | | 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! | | |
| ▲ | holowoodman 4 days ago | parent [-] | | 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. | | |
| ▲ | ColonelPhantom 4 days ago | parent | next [-] | | 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 4 days ago | parent [-] | | 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 4 days ago | parent | prev | next [-] | | 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 4 days ago | parent [-] | | 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. |
| |
| ▲ | igouy 4 days ago | parent | prev [-] | | I think you need to say what you mean by "far worse". | | |
| ▲ | holowoodman 4 days ago | parent [-] | | 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. | | |
| ▲ | igouy 4 days ago | parent [-] | | 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 4 days ago | parent [-] | | 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. | | |
|
|
|
|
| |
| ▲ | hyperpape 4 days ago | parent | prev [-] | | > 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/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 4 days ago | parent [-] | | 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 4 days ago | parent [-] | | And I'm gonna walk everywhere on foot from now on, because I don't have to drink petrol. Are you even aware of the word "tradeoff"? | | |
| ▲ | holowoodman 4 days ago | parent [-] | | Ah, now the excuse for being slow is "tradeoff". | | |
| ▲ | gf000 3 days ago | parent [-] | | "Slow" means nothing without context. The proper context is the performance, productivity, future maintainability, debuggability and a bunch of other factors in relation to the given business requirements and goals. | | |
| ▲ | holowoodman 3 days ago | parent [-] | | The current context is compiler optimizations, as per the original article. That means we are talking about performance as a compiler produces it (or doesn't). |
|
|
|
|
|
|
