[bhuber]

I'm not sure you fully appreciate how tailored the JVM, and hotspot in particular, are to executing OOP oriented code. One great example I can think of is polymorphic methods. In C++ for example, you have to explicitly declare a class method as "virtual" in order for it to be polymorphic - i.e. the version called at runtime is tied to the runtime object instance, not the compile time type. This is because in order to do this in C++, there needs to be an extra lookup in the vtable to find the function address for every virtual function call at runtime. If C++ made all its methods virtual, it would take a significant performance hit from the extra vtable lookup for every function invocation.

In Java, all methods are virtual by default. Java also does the equivalent of a vtable lookup at runtime for function calls, but it has something C++ doesn't have - the hotspot optimizer. For any call site that is executed enough to affect runtime performance, the hotspot optimizer will optimize away the vtable lookup if there are only 1 or 2 method versions called at that site at runtime. This is true for the vast majority of cases. For most of the other cases, where you have 3 or more possible method implementations that could be invoked at a given call site, you would probably have to have something like a vtable lookup at that call site whether you use OOP or not (switch statement, if-else, explicit table of function pointers, etc), so you're not losing performance there either. The end result is, the JVM gets polymorphic methods basically for free in terms of performance.

This is just one example, there are many other clever things the JVM does to make OOP code performant. I don't have a citation, but I do recall seeing a talk (maybe by James Gosling?) where he mentioned that one of the primary design goals of Java was to make "doing the right thing" from an OOP perspective also the best option for performance.

[naikrovek]

it doesn't matter how much the HotSpot JVM is tailored to OOP code. CPUs and RAM are not tailored to OOP in any way.

Procedural code will always be more efficient with CPU and RAM, arrays will always be faster than Lists, being able to control datatype sizing to the byte will always outperform classes, and so on.

java is very fast, please do not misunderstand me. java is much better than it used to be, as well.

Java is not a language chosen when performance is a concern. Java is chosen when you have a giant pile of developers of various levels of skill and you want to pile a ton of rules and linters on them all so they write software in the same way.

[bhuber]

> it doesn't matter how much the HotSpot JVM is tailored to OOP code

This is obviously false. The JVM, or any other compiler for that matter, is what translates the OOP code into CPU instructions. If it does that optimally, it won't matter what design pattern the top-level compiled language used. If it does it poorly, then it will.

> CPUs and RAM are not tailored to OOP in any way.

This is not entirely true. Intel in particular pays a lot of attention to Java performance when benchmarking processor designs, see for example https://www.intel.com/content/www/us/en/developer/articles/t... .

> Procedural code will always be more efficient with CPU and RAM...

First of all, arrays vs Lists and data type sizing are orthogonal to procedural vs OO code. You can write OO code that uses arrays and procedural code that uses lists, and datatype sizing is more related to your choice of language and compiler toolchain than your design patterns.

I think what you're trying to say here is that the performance ceiling for a low level language using simple language primitives (if-else and vanilla function calls instead of classes and polymorphism) that compiles to a binary is higher than that for a high level language that compiles to an intermediate language (or an interpreted language). This is generally true for small code paths - if you need to do a bunch of matrix operations, or data crunching for a small well defined problem, you can generally do it faster in C/C++ than in Java if you put in enough effort. The ceiling part matters though - in general, you have to put in a lot of skill and development effort to realize these differences, and this often grows super-linearly with the size of your codebase for low level languages. If you have a large application that has a lot of code, your overall performance will usually be higher with a high level language because the average performance for any particular part will be much better. Sure, given infinite time and resources you could theoretically do better in C, but nobody has that.

This is reflected in the approach most professionals take in practice when it comes to perf optimization - write most of your code in a high level language like Java or Python because on average it will be faster and less buggy for any reasonable amount of developer effort. For pieces of code that absolutely have to run as fast as possible, write them in C and call out to them from the high level language.

I guess the point I'm trying to make here is lots of people choose java precisely because performance is a concern. It does better than most other high level languages out there, and your average performance for a large codebase will be much better than something like C/C++ given the same amount of effort. As others have noted, it does multithreading better than most too, which is another major performance consideration. I don't care if my Java code is half the speed of the C equivalent if I can easily run 40 cores at once - or 40000. I think languages like Rust and Swift may let us have the best of both worlds in the future, but that remains to be seen. For now, the only time lower level procedural languages win is when you need a relatively small codebase to run absolutely as fast as possible.

[naikrovek]

> If it does that optimally

ah, the "sufficiently smart compiler" argument. There is no such compiler, FYI, and there may not ever be. Not for every situation that developers are creating in Java today.

it's a matter of hitting your CPU cache as often as possible. Neither javac nor the runtime has any freaking clue how to do that, but you, as a developer, do. When you write Java, you can't do a lot to control how that JVM arranges data or how it fetches it from RAM, partially because of OOP, partially because of autoboxing/unboxing, so you wind up missing the cache a lot more unless you create a bunch of primitive types and use those, and that that point, why are you writing Java?

I'm not saying Java is bad. I'm saying that it is not the fastest language you can use. You seem to be arguing that it is, or that it could be. It cannot.

> average performance for a large codebase will be much better than something like C/C++ given the same amount of effort.

absolutely not. Maybe if you're fully skilled in Java and new to C or C++, but if you are equally skilled in both, you would never choose Java for performance alone.

[kaba0]

There is an interesting presentation titled death of optimizing compilers, where it is claimed that programs increasingly are either in their hot path where performance is absolutely crucial and not even C/C++ is sufficiently low-level (you can achieve 2-3 orders of magnitude faster code by hand-optimized assembly), or on cold paths where even Bash would suffice.

Nonetheless, I found that it is easy to find these hot spots and they are trivial to “fix” in java for optimal performance, by simply using a primitive array. At every other place, Java is more than fast enough even with the occasional “jumping around”.

Also, haven’t seen a study on that but would be interested in Java’s defragmentation skills (due to moving GC). Malloc implementations can fragments a lot, and cold path code jumps around a lot. Wouldn’t be surprised if Java would fair quite well here.

[naikrovek]

I would love to see a video game implemented in Bash with the hottest spots implemented in Assembly, just to see how poorly that would perform.

I work for a company that has AWS Lambdas which are invoked 10s of trillions of times per year, with about 45% of that happening in a single month, and another 45% happening 6 months later, also within a single month.

I cannot imagine what our AWS bill would be like if those lambdas ran Bash. 100x larger? At least.

Performance matters. It's not obvious how much it matters until you look, but it matters. There are zero users who will complain that an application makes them wait less than it did previously. There are zero managers who will complain that their AWS bill gets lower because code takes less time to run and uses less RAM.

I have no idea why anyone would even begin to argue the opposite.

[kaba0]

I didn’t write that I agreed with said presentation, but it was interesting, and a good take away is that if you have such a scorching hot loop that iterates over megabytes of data, a compiler may not be sufficient even in low-level languages. (Think of video codecs). And the other side, routine optimizations done on cold paths may not be as worthy (the bash line was me exaggerating the effect - but just think of any Python deployment, they are basically that, slow code calling into optimized libs in C and Fortran)

[al_mandi]

I'm curious about the cost of hosting if you're using plain ol' VMs instead of lambdas (EC2, etc.). What are those functions written in? Unless you're going to say C/C++/Rust or a similar language, I'm not sure there will be any significant variance.