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

Java is fast, code might not be

jvogel.me

Post reply on HN
Print view View original

41–50 of 259 posts

Re: Java is fast, code might not be

#41

Post by this_user »

jandrewrogers wrote: post #28

You can write many of the bad examples in the article in any language. It is just far more common to see them in Java code than some other languages. Java is only fast-ish even on its best day. The more typical performance is much worse because the culture around the language usually doesn't consider performance or efficiency to be a priority. Historically it was even a bit hostile to it.

Performance is really not Java's issue. Even bad Java code is still substantially faster than the bulk of modern software that is based on technologies like Python or JavaScript/Node.js.

Re: Java is fast, code might not be

#42

Post by belfthrow »

kyrra wrote: post #10

First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.

I really hate how completely clueless people on hn are about java. This is not, and has not been an issue for many many years in Java and even the most junior of developers know how to avoid it. But oh no, go and rust is alwaayssss the solution sure.

Re: Java is fast, code might not be

#43

Post by pjmlp »

kyrra wrote: post #10

First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.

Excelsior JET, now gone, but only because GraalVM and OpenJ9 exist now.

The folks on embedded get to play with PTC and Aicas.

Android, even if not proper Java, has dex2oat.

Re: Java is fast, code might not be

#44

Post by shermantanktop »

koakuma-chan wrote: post #2

As much as I love Java, everybody should just be using Rust. That way you are actually in control, know what's going on, etc. Another reason specifically against Java is that the tooling, both Maven and Gradle, still stucks.

I’ll never understand the impulse to tell the entire world what to do based on your own personal preferences and narrow experiences.

It gets a reaction, though, so great for social media.

Re: Java is fast, code might not be

#45

Post by FatherOfCurses »

bearjaws wrote: post #4

JavaScript can be fast too, it's just the ecosystem and decisions devs make that slow it down. Same for Java, I have yet to in my entire career see enterprise Java be performant and not memory intensive. At the end of the day, if you care about performance at the app layer, you will use a language better suited to that.

"Enterprise Java"

Factories! Factories everywhere!

Re: Java is fast, code might not be

#47

Post by maccard »

wiradikusuma wrote: post #25
maccard wrote: post #13

Earlier quoted context omitted.

My experience with the defaults in JavaScript is that they’re pretty slow. It’s really, really easy to hit the limits of an express app and for those limits to be in your app code. I’ve worked on JVM backed apps and they’re memory hungry (well, they require a reallocation for the JVM) and they’re slow to boot but once they’re going they are absolutely ripping fast and your far more likely to be bottlenecked by your D…

Compile it to native (GraalVM) and you can get it fast while consuming less memory. But now your build is slow :)

The minute a project has maven in it the build is slow. Don’t even get me started on Gradle…

Re: Java is fast, code might not be

#48

Post by pjmlp »

bombcar wrote: post #12
kyrra wrote: post #10

First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.

Do none of the JVMs do that? GraalVM?

They do, to add to another comment of mine elsewhere, JIT caches go all the way back to products like JRockit, and IBM JVM has and it for years in Maestro, now available as OpenJ9.

Too many folks have this mindset there is only one JVM, when that has never been the case since the 2000's, after Java for various reasons started poping everywhere.

Re: Java is fast, code might not be

#49

Post by pron »

kyrra wrote: post #10

First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.

You mostly need a recent JDK. Leyden has already cut down warmup by a lot and is expected to continue driving it down.

https://foojay.io/today/how-is-leyden-improving-java-perform...

https://quarkus.io/blog/leyden-1/

Re: Java is fast, code might not be

#50

Post by wood_spirit »

A subject close to my heart, I write a lot of heavily optimised code including a lot of hot data pipelines in Java.

And aside from algorithms, it usually comes down to avoiding memory allocations.

I have my go-to zero-alloc grpc and parquet and json and time libs etc and they make everything fast.

It’s mostly how idiomatic Java uses objects for everything that makes it slow overall.

But eventually after making a JVM app that keeps data in something like data frames etc and feels a long way from J2EE beans you can finally bump up against the limits that only c/c++/rust/etc can get you past.

Post reply on HN