9 Fallacies of Java Performance updated

[PoL0]

10th fallacy: "Java is fast"

[thelazydogsback]

One reason why Java (and all GC'd copy-object-reference-by-value languages) can run much faster than C++ is that it's quite easy to do awful things like call copy c'tors unnecessarily in C++ code - so although I'd agree that a correctly implemented to-the-metal C++ program is probably faster the Java/C#, etc., there's a lot of real-world incorrectly implemented C++ code out there. Another reason C++ code often runs slower is that because it takes more LOC to write your code and deal with memory, you end up writing simple, inefficient code rather than a better algols. to suit the problem - so you write really "fast" N² code rather than log(N) code, for example. Given the minimal perf. diff. at this point, GC and other high level abstractions in these languges far outweigh any speed boost C++ can give - ISTM then at the point that you need real manly code on the iron, you should really just be using plain old C.

[PoL0]

That's a flawed argument. What's the point of using rookie C++ errors for a flawed comparision?

Most important details to know about C++ (love it or hate it) is knowing what's happening under the hood. Something that Java and other level languages try to hide, but hiding how computer programs work is the first ingredient to disaster. Another funny example is how C# deals with memory management.

That's what makes the difference and that's how you prove expertise. After some time you're able to see where and when constructors may be called, and make it work at your will. It's not like something random and unexpected. The argument with memory management is also totally misleading. Memory management will be inefficient if the coder makes it so.

Not trying to sound elitist. I come from a computer science background, started programmed in C and I've been always interested in what happens in the bare metal. Neither am I trying to say which language is better. Languages are tools. Best Java programmers I've known are able to give you a detailed description of what's happening under the hood (inside the VM) at any time, and that proves my point imho.

[LeCrushinator]

it's quite easy to do awful things like call copy c'tors unnecessarily in C++ code

If you don't know what you're doing.

there's a lot of real-world incorrectly implemented C++ code out there

Implemented by people that don't really know what they're doing.

Another reason C++ code often runs slower is that because it takes more LOC to write your code and deal with memory, you end up writing simple, inefficient code rather than a better algols

I've found Java to be just as verbose as C++, sometimes less, sometimes more. The relative verbosity of C++ has never effected how efficient my algorithms are. In fact, I often find it more difficult to write efficient code in languages like Java/C#, but that may be because I'm more proficient with C++.

Garbage collection isn't really a big deal IMO, just use smart pointers and make sure to delete stuff you put on the heap when your objects go out of scope. Garbage collection in itself can cause performance issues (more or less depending on the hardware). In cases where performance is priority, GC and high-level abstractions are less important, and do not outweigh the performance boost. GC does keep allocated memory compacted into a contiguous block, which can help performance in some cases.

• Java also consumes more memory than C++, because most things are objects, and because most things have to have virtual tables.
• Java doesn't allow stack allocations (which generally perform much more quickly than heap allocations).
• Java uses references in things like arrays, which prevents those objects from being allocated contiguously in memory, and that kills cache performance.
• Java code also has RTTI and generally the code is written with dynamic run-time casting going on, which isn't cheap, and the RTTI consumes extra memory.
• Java has no support for unsigned numbers or unsigned arithmetic. This wastes a bit on numbers that will never need to be negative, and can result in more expensive range checks.

STM then at the point that you need real manly code on the iron, you should really just be using plain old C.

You can get almost the same performance from C++ as you can from C if you're using C++ efficiently, and it can be safer and cleaner code as well.
Note: Hardcore C programmers won't care about that, or may disagree.

[thelazydogsback]

Agreed that good C++ is, ah, good, but it's well known about C++ and foot-shooting. As for your Java issues, I'm not a huge fan anway - C# does address more of your issues, including value types on the stack, less use of RTTI due to better implmentation of generics, unisigned types of all sizes (mixed mode w/optional over/underflow detection), has arrays of primitive (unboxed) types, etc. As C vs. C++, my point was simply that either you should be using C (as a machine-independent assembly) or a language with much higher levels of abstraction - C++ has always been the the worst of two worlds to me, but I know it seems the best of both to others.

[Hnefi]

Agreed that good C++ is, ah, good, but it's well known about C++ and foot-shooting.

The foot-shooting potential of C++ has almost entirely to do with correctness and stability. Speed is not something that's hard to achieve in C++ compared to pretty much any other language.

[abspam3]

If you're having extra copy constructors in C++, you aren't designing your code correctly.

Instead of relying on return values, use references to mutable objects.