Hacker News Reader

Comment by sremani | Hacker News Reader

I understand JVM is battle tested on Linux, *BSD, where CLR would have to catch up, but are there any technical reasons say JVM perfs better than CLR on windows.

View on HN

> but are there any technical reasons say JVM perfs better than CLR on windows

Considering the amount of man-hours that have gone into both, the exact reasons are probably hidden under a whole bunch of implementation details.

That being said, I've run benchmarks where the JVM (version 1.8) outperforms C++ and Fortran... The JVM seemingly optimizes everything, and the amount of fine tuning you can do is amazing.

I've never heard of the CLR coming close to Java performance on large-ish apps or tasks, all else being equal.

Why every Java app is so slow and memory hungry?!!

There's plenty of slow, memory hungry C++ apps too. Just enterprise software things...

Plenty != every. And comparing IntelliJ and Visual studio 201*, there is no chance Java is winning.

There are fast, optimised Java apps as well. IntelliJ is actually a good example - on my laptop it starts in a few seconds, the UI is snappy and responsive, it looks native. Back when I used Eclipse I thought the same as you; Java apps must just inherently suck. The difference in performance between IntelliJ and Eclipse put that idea to bed for good.

The real reason Java apps are often associated with being big and heavy is less to do with the technology and more to do with the fact that it's so often used for bespoke enterprise apps where there's no competition and so little incentive to optimise (vs add new features).

I agree that IntelliJ is OK comparing with other Java apps. It is never near performant. Visual Studio being 32 bit app is still much faster than 64 bit IntelliJ, given that IntelliJ can use much more memory. Every time, people complain about IntelliJ, they are told that they will need better hardware. The reason Enterprises chose Java, is because they don't care about performance that much.

Visual Studio being 32 bit is an embarrassment for Microsoft in this day and age. That's exactly the kind of technical hole that JetBrains avoided when they bet on Java to write their IDEs in. The transition for them from 32 bit to 64 bit was extremely smooth despite having a huge plugin ecosystem. I've read about the bizarre hacks people with big Visual Studio projects have to use to ensure they can actually load them, that's just not sustainable.

I haven't compared the speed of a recent VS vs IntelliJ as I use a Mac now (another benefit JB got from going with Java). But of my complaints about IntelliJ none are really related to speed.

BTW if it's typing responsiveness you're thinking of, I recall that JB had some inefficient drawing algorithms which they've optimised in very recent builds (or it might even be an experimental feature still). It could cause issues on slow graphics cards. That isn't a Java issue though, it was just IJ using inefficient graphics code.

I have used latest edition of IntelliJ on OsX. IntelliJ is acceptable but not smooth at all considering that I have 16g ram with 1tb Ssd. And font rendering due to the jvm swing bug is hurting eyes. It is far fetched to say the experience is any pleasant. To fix the issue of Java, jetbrain bundles their custom built jdk

I use IntelliJ on the same setup and don't see any font issues. I haven't noticed any lack of smoothness either, but perhaps we have different standards for that.

Another important performance issue is related to Java's handling about generic type erasure and auto boxing. This is one of the biggest design issue comparing with C#'s handling. So manipulating bytes is a pain. And there is even no unsigned byte. Benchmark does not represent real world use case. I don't feel Java is much faster than Python or Ruby. But there is too much boilerplate code comparing with C#. The pure Java language is clean. But with Spring framework and various Apache common, endless different logging framework, it makes the language such a hassle to deal with. Just my 2 cents.

Do you have some links to these performance comparisons for apps?

JVM optimizes and reoptimizes as your code runs, so that "hot spots" run very quickly. Last I heard, CLR still doesn't do this... it JITs once only.

This multitiered approach does not necessarily make the end result faster. It is in vogue to do this, and for startup performance having a baseline JIT can be beneficial, but for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time.

> ... for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time.

Isn't this statement pretty much the entirety of the reason to implement multi-tiered JITs? Do a fast JIT with few optimizations to get out of interpreted mode. Then do a slow JIT after you've collected enough statistics to make good optimization decisions.

To me that's like saying compression algorithms don't necessarily make data smaller. It's true enough, but you can still make general comparisons between approaches.

If your work has an "inner-loop" situation, then the JVM can optimize the heck out of it using statistics specific to this particular execution. That's huge.. it opens up all kinds of concrete optimizations that aren't possible with static analysis alone (precomputing call targets, knowing what to inline, etc.). I'd wager this is a major factor in cases when the JVM occasionally outperforms C.

But no, it doesn't necessarily help.

Actual gathered statistics say you're wrong. Profile guided optimisations can easily add 20% performance or more. And for that to work, the easiest path for the developer is a tiered JIT. More concretely, you can disable the tiered JIT on the JVM and find out what it buys you (and there are people who have done this).

The fact is that before the JVM has a chance to optimize the code, the app already restarted by the user unless it is some long running server process. On the server side, JVM is so heavy, normally there is only 1-2 heavy JVM running for web server and database driver on the entire machine. On the client side, Java is a joke. Though users now have more choices: Swing, AWT, JavaFx. Every one of these is hard to use comparing with C# or Qt. Most native platform developers hate Java, including OSX developers.

Reply on news.ycombinator.com