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

121–130 of 373 posts

Re: The JVM is not that heavy

#121

Post by pjmlp »

snuxoll wrote: post #55
froh42 wrote: post #35

Earlier quoted context omitted.

Haha, AOT native compilation. This comes back time and time again. AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. Where AOT really makes sense is for an interactive app on a mobile device where you don't care about the last millisecond of performance bu…

Later versions of .Net don't do dynamic profiling, the .Net CLR is much less sophisticated than the JVM, the first time you invoke an IL method it is compiled to machine code, and that same code will execute for the rest of the lifetime of that image.

That isn't 100% correct, you can write CLR plugins that control that behaviour.

Re: The JVM is not that heavy

#122

Post by steveklabnik »

snuxoll wrote: post #64
flavor8 wrote: post #40

Earlier quoted context omitted.

Which tooling specifically? Going from Java to Python a couple years ago I was in shock about how immature the tooling in the Python world is by comparison.

Good question, I still haven't found something that trades blows with maven in any other programming language. I've made my peace with setuptools for python, but .Net/Ruby/Go/Rust/etc. are all lacking in one way or another.

What could Cargo do for you that you miss from Maven?

Re: The JVM is not that heavy

#123

Post by eveningcoffee »

akvadrako wrote: post #118
eveningcoffee wrote: post #115

Earlier quoted context omitted.

1.5 is huge, except it is completely wrong. JVM startup time is within fraction of the second.

You are right, I was just going with what the grandparent said. But I think with normal amounts of class scanning and other overhead, 1.5 seconds becomes the practical normal. Certainly the JVM startup always feels slow, in my experience.

Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html

Re: The JVM is not that heavy

#125

Post by kodablah »

martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

As another commenter mentioned, I think this is much more the programmer and less the language. Sure, the language may recommend certain approaches which carry across teams differently, but it still often comes down to the app, not the language. I implemented a rudimentary Java AOT targetting Go and the trimmed-down stdlib grew so big Go took hours compiling it (granted some of that is how I approached OOP and what not).

Re: The JVM is not that heavy

#126

Post by akvadrako »

eveningcoffee wrote: post #123
akvadrako wrote: post #118

Earlier quoted context omitted.

You are right, I was just going with what the grandparent said. But I think with normal amounts of class scanning and other overhead, 1.5 seconds becomes the practical normal. Certainly the JVM startup always feels slow, in my experience.

Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html

That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.

Re: The JVM is not that heavy

#127

Post by astrodust »

gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

It would be great to have a runtime for JRuby that's really stripped down to just the necessities. The spin-up time of the jruby environment is painful and it seems predominantly the fault of the JVM's baggage.

Re: The JVM is not that heavy

#128

Post by it »

I keep seeing plenty of evidence that the JVM is indeed heavy. When I was working at a startup and we were running Solr on the JVM, it kept running out of memory and crashing. When I tried using Clojure I was irritated by the startup time of the REPL on the JVM. More evidence: http://stackoverflow.com/questions/13692206/high-java-memory....

If you want something light like Clojure and don't need any Java libs, try Pixie. https://github.com/pixie-lang/pixie

If you want something light not like Clojure, Go is a great choice. It's fast to compile, fast to run and doesn't gobble up your memory unless you force it to.

Re: The JVM is not that heavy

#129

Post by cnlwsu »

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…

They also have never caught up feature wise, and actually have gotten further behind since initial release. Also the benchmarks are lies (tbf, all benchmarks are lies).

Re: The JVM is not that heavy

#130

Post by doggydogs94 »

The biggest problem with Java is not the JVM, but versioning. Many Java applications encounter difficulties when the wrong version of Java exists on a computer. This leads to many siloed computers to maintain.
Post reply on HN