Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

11–20 of 373 posts

Re: The JVM is not that heavy

#11

Post by bpodgursky »

sandGorgon wrote: post #7

I used to think this too, until I came across http://www.scylladb.com/ It is a fork of cassandra written in the Seastar c++ framework and is drop-in compatible with cassandra. Claims 10x increase in performance. I always thought there was a few percentage points difference - never a 10x performance difference between java and c++. And that too for a project with as many man hours and facebook-scale tuning as cassandr…

If something sounds too-good-to-be-true, it probably is.

I don't love Cassandra, but it's not because it's written on the JVM (full disclosure, we roll our own JVM key-value datastore https://github.com/liveramp/hank).

If your random-access keystore is limited by anything except network and disk latency, you have bigger problems.

Re: The JVM is not that heavy

#12

Post by saosebastiao »

Interesting that all the comparisons were with server frameworks. As if anybody ever cared about a few hundred megabytes of overhead on a server. Hell, even a bloated JVM implementation fits in most server L3 caches.

On the desktop, laptop, phone, or embedded environment, the JVM is heavy. It starts up slow, jars carry around ridiculous amounts of dead dependencies, garbage collectors require immense amounts of tuning, etc. And we shouldn't really expect otherwise. If you can't even keep your VM in cache, how are you supposed to have fast application code?

Specialty closed source JVM vendors have done wonders in terms of improving this problem...but it's still an uphill battle. AOT native compilation down to machine code is becoming more popular because of the proliferation of resource-constrained environments, and it will take time for new languages/compilers to take over, but take over they will.

Re: The JVM is not that heavy

#13

Post by jhh »

I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see:

1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?).

2. Memory usage of Java objects is quite heavy. See this article: http://www.ibm.com/developerworks/library/j-codetoheap/index...

3. The heavyness of the ecosystem in terms of the magnitude of concepts and tools being used and the enterprisy-ness of libraries.

Re: The JVM is not that heavy

#14

Post by echlebek »

sandGorgon wrote: post #7

I used to think this too, until I came across http://www.scylladb.com/ It is a fork of cassandra written in the Seastar c++ framework and is drop-in compatible with cassandra. Claims 10x increase in performance. I always thought there was a few percentage points difference - never a 10x performance difference between java and c++. And that too for a project with as many man hours and facebook-scale tuning as cassandr…

If you investigate what they actually do to achieve those numbers, it's much less simple than just rewriting Cassandra in C++. For example, they use their own TCP stack and make use of vector intrinsics.

Re: The JVM is not that heavy

#15

Post by vvanders »

lnanek2 wrote: post #10
vvanders wrote: post #4

Start-up times are still an issue with Clojure on the JVM. For instance with Android I've found the initialization times to be pretty much a show-stopper for any application development.

I don't know anything about Clojure, but in modern Android development, Instant Run patch files mean installation isn't even done each change any more. Even then, you can avoid a lot of installation time by using an emulator on a fast development machine instead of a real device. For most of Android's life the emulator has been disgustingly slow, but for installation times, it has benefits. Meanwhile restoring from a…

It has nothing to do with that and more to do with that last time I tried it the start-up times for an app was multiple seconds on top of base start times.

Given how often Android evicts apps that's something I'm not comfortable with shipping. Would love to use Clojure but it was definitely a show-stopper for us.

Re: The JVM is not that heavy

#16

Post by saosebastiao »

vvanders wrote: post #4

Start-up times are still an issue with Clojure on the JVM. For instance with Android I've found the initialization times to be pretty much a show-stopper for any application development.

Clojure on the JVM is way worse than java...but the JVM only contributes to a tiny portion of that. The real problem is that every clojure process has to bootstrap the entire language and compile every library before it can begin executing.

Re: The JVM is not that heavy

#17

Post by pron »

sandGorgon wrote: post #7

I used to think this too, until I came across http://www.scylladb.com/ It is a fork of cassandra written in the Seastar c++ framework and is drop-in compatible with cassandra. Claims 10x increase in performance. I always thought there was a few percentage points difference - never a 10x performance difference between java and c++. And that too for a project with as many man hours and facebook-scale tuning as cassandr…

The choice of C++ is responsible for only a very small part of the performance difference. ScyllaDB uses different low-level algorithms, many of which could have been done in Java as well. That the Cassandra data model works well with the sequential processing approach of Seastar makes the effort of implementing in C++ manageable. In general, concurrent data structures in C++ require significantly more effort than in Java, and rarely yield performance improvements that are worth it, unless you're memory-bound. In sequential code it's easier to surpass Java's performance, but even that difference is diminishing (and expected to be dramatically reduced when value types are added to the JVM). Usually, the only significant overhead you must be prepared to pay is in RAM, and in exchange you get better performance-per-effort.

Re: The JVM is not that heavy

#18

Post by outworlder »

Interestingly, the author does not touch startup times.

Frankly, for server-side loads, no-one cares how much your runtime weights, be it disk space, download size and even memory (heck, my last project required developer workstations with at least 96GB).

There are all sorts of environments where that matters. And that's one of the reasons why Clojure didn't catch on on Android.

Re: The JVM is not that heavy

#19

Post by linkmotif »

This interview with Bob Lee is really interesting on this topic: https://www.infoq.com/interviews/lee-java-di.

Apparently, Square was first built out on Ruby with the mindset that the JVM is an old clunker.

Fast-forward a few years they switched to the JVM because it was faster and the language (I know, not related) provided compile-time safety.

Re: The JVM is not that heavy

#20

Post by rb808 »

Not just heavy but I really don't like all our processes named "java" with stupid -D cmd line parameters. A Nice native binary app will let you can name it what you want with config as you like it.
Post reply on HN