18 points

So, Java is fast if you use it like C.

permalink
report
reply
9 points
*

Its even better…

In C/C++ you have to create/destroy objects, deal with pointers (**& for the win!). As a result the average C/C++ developer has to think about alot more than the average Java developer.

In a previous job there were a lot of legacy C and C++ applications. They wanted to replace some components with Java local applications because Eclipse RCP was the new cool thing.

So we would build it and then have 2-4 weeks for performance tuning. It basically involved one person from the team attaching Yourkit profiler and either nudging code to pure OO or C like procedural at bottleneck points.

Every single time the result used less CPU and RAM than the C/C++ application when running through the original applications test packs. Even when those applications had gone through multiple rounds of performance tuning.

We got given some time to figure out why, our conclusion was while any one part of the Java application would be slower, the reduced mental load lead to better performance in total.

permalink
report
parent
reply
14 points

Person reinvents data oriented design.

permalink
report
reply
9 points

Every language is fast, as long as it can be somehow (at least) jit compiled, and you’re not allocating much.

permalink
report
reply
8 points

When I worked for Amazon, someone had created a command line tool to be used in builds, but repeatedly starting up JVMs is painfully slow. I rewrote the app in C++ and it could be invoked 81 times vs one invocation of Java version.

If I need speed, I’ll use C++. If I need developer productivity, I’ll use Ruby.

permalink
report
reply
6 points

Why in the world would you rewrite it when you could take an hour and get it compiling with graalvm and it would be just as fast as c++?

permalink
report
parent
reply
8 points

Tbf he’s also suggesting that Ruby is the most dev friendly language he could use, so I’m already a bit skeptical lol

permalink
report
parent
reply
1 point

I mean, I agree with them on that. It’s very dev friendly. You definitely shouldn’t be building large scale apps in it, but it’s more readable than almost every single language out there. But rewriting a whole app in a new language instead of just using the tools available to get the best of both worlds is just a bad idea.

permalink
report
parent
reply
2 points

I’ve never tried Graal. Is it easy to use? Like, is it a dropin replacement for javac or what?

permalink
report
parent
reply
2 points

It’s pretty easy to use. If you are using a lot of reflection you might have trouble, but if you’re using a standard large framework like spring, quarkus, or micronaut you’ll be fine. Quarkus makes it dead simple honestly. We deploy all of our Kotlin lambdas on AWS using Graal. It’s faster than node and much easier to write safe code.

permalink
report
parent
reply
-1 points

And this is how people build the largest (in terms of the actual size of the binary on the disk) command line utilities in history.

permalink
report
parent
reply
2 points

I don’t know why you would think that. GraalVM can compile tiny tiny packages, and you can easily remove features from the JVM if you don’t need them. It’s a terrible myth that JVM means massive binaries.

permalink
report
parent
reply
2 points

…If you need both, you use Rust

permalink
report
parent
reply
1 point

I’m not so sure if the JVM startup was the culprit in your situation. The Computer Language Benchmarks Game shows that even for short runtimes, the startup doesn’t affect their performance numbers that much

permalink
report
parent
reply
5 points

That link just compares benchmarks with and without warmup, but not without startup. The JVM’s startup can take upwards of 2 seconds, depending on the program.

permalink
report
parent
reply
2 points

Oh, I’m dumb. Thanks for clearing this up :)

permalink
report
parent
reply
0 points

You hand me till “Ruby” ROFL.

permalink
report
parent
reply
2 points

This is actually a very cool and insightful blog post. I’d have liked if the code was worked better into the written text however. I mean it didn’t dive deep into it’s Java usage or the specifics of the JVM, other than it being very well optimized for short lived objects.

However, the precise performance numbers should be taken with a grain of salt. I’d classify this as a micro benchmark and those can often be influenced by stuff like cache locality and other small details and could look quite different on other machines.

permalink
report
reply

Java

!java@programming.dev

Create post

For discussing Java, the JVM, languages that run on the JVM, and other related technologies.

Community stats

  • 33

    Monthly active users

  • 186

    Posts

  • 276

    Comments