Java Performance Urban Legends

An anonymous reader writes "Urban legends are kind of like mind viruses; even though we know they are probably not true, we often can't resist the urge to retell them (and thus infect other gullible "hosts") because they make for such good storytelling. Most urban legends have some basis in fact, which only makes them harder to stamp out. Unfortunately, many pointers and tips about Java performance tuning are a lot like urban legends -- someone, somewhere, passes on a "tip" that has (or had) some basis in fact, but through its continued retelling, has lost what truth it once contained. This article examines some of these urban performance legends and sets the record straight."

Comments

The best tip

[Anonymous Coward]

The best tip in the article, which really applies to any language (even to choice of languages), is IMHO
"Save optimizations for situations where performance improvements are actually needed, and employ optimizations that will make a measurable difference."

Antidote

[Henry V .009]

One thing to remember is that Java is a 'marketed' language. Hence, be aware of inevitable corporate propaganda. That's not to say that Java is bad, but it is heavily pushed.

Here's a bit of an antidote: Why Java will always be slower than C++

Re:Antidote

[WolfWithoutAClause]

My advice is don't follow the link, it's trash. Check this out:

People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.

What? A constant time operation in an 'n' loop is O(n), but then again, the loop is O(n) to start with. Add another loop and you get O(n^2) versus O(n^2). The constant of proportionality has changed, but that's all. If you were using C++, you'd probably call a constructor and possibly destructor anyway; so the difference is not nearly as much as you'd expect; and java heap allocation is only about 3 instructions anyway on a decent VM. This article is total junk.

Re:Antidote

[Anonymous Coward]

Java will be faster than C++, and very soon (if it isn't already) on the condition that Sun continues to exist for a while.

Java does virtual method inlining. That, alone, makes it potentially faster than C++. A slightly more intelligent garbage collector designed to decrease page-faults later, and presto, C++ is the slow language.

[Note that Garbage Collection can't scale very well on multiple CPU machines, so Java still won't be the be-all-and-end-all language unless it divides its objects into seperate "memory pools" a la the Apache Portable Runtime, and GCs them all seperately and scaleably.]

Even once every test shows that Java is faster - and that is almost certain to happen, because ahead-of-time compilers simply can't compete with runtime-compilers (in principle), people won't stop *using* C++, because they won't believe that Java could ever be fast. But Java is definately the way forward for object-orientated languages.

You don't have to like OO, of course. And Java will never be as fast as C. But if you like OO, you have to like Java.

The reason people think Java is slow is generally due to Swing. Swing is just a piss-poor kind of UI framework. If it was compiled with an ahead-of-time compiler, it would just be worse. You shouldn't judge a language by one of its libraries, however.

(I am not blinded by the holy light of Sun - there are legitamate complaints you could make against Java, usually to do with memory. The article you linked does not invoke any one of them)

-Emlyn

Re:Antidote

[digicosm2]

errr...

Saying "Java will always be slower than C++" is like saying that there will always be less graduate students than undergraduates. Java and C++ live in the same Von Neumann-ian world, but C++ is allowed to muck with pointers, and Java isn't. Moreover Java has garbage collection.

However, I dare say that the time that a programmer saves by not mucking around with pointers is far more valuable than the time saved by typical C++ optimization. This may not hold true in performance-critical domains (like game programming), but for the vast majority of programming problems, it's fine.

If performance was always critical, why do any of us use Perl or Python? To save time.

Re:Antidote

[j3110]

It's more junk than you even pointed out :)

My favorite was the cast issue. He fails to recognize that the code he is talking about is run once, then it is a static cast just like most people use in C++. Something that must by dynamically casted at runtime, on the other hand, will be much faster in Java since it doesn't have to figure out the casting for an object every time you cast. It basically does it once, then it will be able to cast any object of the same time to the same casted type as before.

It's complete idiocy by a person who hasn't spent any significant time using Java.

If you want to critisize Java you must:

A: target memory usage, site a specific API and why in your OPINION you don't like it, or target startup time.

B: have not used C++ techniques of optimization on Java

C: have tried the latest JVM.

D: have checked the bug parade, and found that the issue you are talking about is not currently being fixed or has been in the bug parade for a very long time.

If you don't follow all those, then you are really just taking pot shots at a system that works quite well for a LOT of people. I've never met anyone that didn't like Java after they played with it for a while (except back before 1.3).

There is a SSH server written in Java now that supports all the features that OpenSSh does... I think I'm going to give it a try... no more CRC buffer overflows for me.

kind of right, and that's a problem

[g4dget]

While the article has a number of glaring errors, the general point the author is making is right that in terms of raw computer performance, Java has become quite fast.

But that's not really a good thing. Sun pushed on the JIT on the theory that that would address performance problems. It didn't. The Perl and Python runtimes are much slower than Java's, but Perl and Python applications generally start up much faster and are considerably more responsive.

Java is as sluggish as ever, and more bloated than it has ever been. What is really responsible for Java's poor performance for real-world applications is its class loading, memory footprint, and just plain awful library design and implementation.

Enough about the things Java can never fix.

[Anonymous Coward]

I'm all for calling a spade a spade, but you can't have your cake and eat it too.

JNI is the NATIVE INTERFACE. For those that don't already know, that's the interface to the underlying operating system. If the OS misbehaves, hiccups, or is inconsistent, when did it become JAVA's responsibility to clean up? When somebody decided that JAVA was getting a black eye because OS call foo(bar) was crashing the application, or better yet didn't behave exactly like foo(bar) on every OS that provides the JVM.

Don't like AWT? Well mabye that's because it's built on top of JNI. Enough said.

Don't like Swing? Well you'd better like AWT. If you don't want the OS to do your GUI work and you don't want the JVM to do your GUI work, mabye you should just get a dry erase marker. You can draw the boxes you need on the screen provided you use a tissue between display updates.

String requres no more attention than any other bit of JAVA code. If you create dozens of objects for the sole purpose of garbage collection, you either just learned JAVA, you're unaware of what you're doing, or you don't care.

And about garbage collection. JAVA's garbage collection may not be your cup of tea, but neither are the memory leaks that are still being cleaned up in systems that lack automatic garbage collection.

So pick your posion. If JAVA isn't perfect, that dosen't make it horrible. JAVA is a good language by most standards, but be honest by stating that it isn't good by your standards.

My biggest reason for liking JAVA is that it forces people to stop writing bad C code. Which is exactly what it was designed to do.

Bigger synchronization myths

[Waffle Iron]

The "synchronization is slow" myth is a very dangerous one, because it motivates programmers to compromise the thread-safety of their programs to avoid a perceived performance hazard.

However, the article perpetuates another myth: "Synchronization should be easy. The more things you synchronize, the better off you are."

My hard experience says otherwise. First off, making multithreaded programs work correctly is very hard. Therefore, multiple threads should be avoided if at all possible. You can avoid a lot of these problems in many cases if you use a function like "select()" in a single-threaded program (which, IIRC, Java unfortunately doesn't support). Even though it looks harder to program, it ends up being easier to debug.

However, sometimes you just can't avoid threads. IMHO, adding "synchronize" as a language keword and encouraging easy creation of threads was a mistake. That doesn't begin to solve your problems. For example, it does nothing to help you avoid deadlocks. In fact, sprinkling synchronized blocks around your program is a recipe for deadlocks and unexpected timing-dependent buggy behavior.

If you must use multiple threads, there should be one main thread that runs almost all of the program's logic, and a set of highly constrained, carefully controlled worker threads. These threads should not interact with any other (mutable) data structures in the program. Ideally, there should be at most two synchronization points in the program: a work queue and a results queue. The elements of these queues should package up all of the state needed for a worker thread to solve a piece of a problem or deliver its results.

With an approach like this that has minimal synchronization, there's no need to add a keyword to the language or put synchronization into many library container classes. And of course, performance is hardly an issue at all when you only synchronize twice per worker thread run.

Why do poor coders have tunnel vision?

[ishmalius]

Each tool for its own purpose! If the best language for the task is Java, then use Java. If the best language for your project is C++, then use C++. If it happens to be Billy Bob's Bug-Free Language which suits the job best, well, then, use that one.

Yes, if I need speed, I use C, the same as anyone else. If I am writing a Web application, I use Java. That's an area where Java excels. And maybe I'll get lucky enough to be able to code a project in Assembly or Lisp, who knows? Programming does not follow the "jack of all trades, expert at none" theory. General concepts map well across the spectrum.

I find it discouraging that there are so many programmers who only want to learn as much about their job, as to merely be good enough . Don't they feel any pride, or any desire to excel at something?

Coders who can only handle one language should be paid minimum wage; that is all they are worth. That is because it is neither the language nor the implementation that is important. It is the knowledge of how to program which will ensure your career and pay your bills.

a lot

[Trepidity]

A lot of them are things that actually used to be good advice, but for some reason or another (changes in hardware, compilers, etc.) aren't anymore. For example, it used to be a good idea in C to iterate through arrays by incrementing a pointer and dereferencing it instead of incrementing an index and then using array subscripting -- that way you had one increment per iteration, instead of one increment plus one offset calculation (basically you saved the addition that takes place during the array subscripting). However, on many modern C and C++ compilers in many situations, array subscripting will actually be faster than the pointer-incrementing method, because it's easier for the compiler to perform certain optimizations with. [Reference: Michael J. Scott, Programming Language Pragmatics (Morgan Kaufmann, 2000).]

There's quite a bit of other stuff like this out there as well.

Java not always slower

[AT]

Java is not always slower. Java's interpreted nature is generally seen as a weakness, but it has advantages too. For example, the JIT has profiling data immediately at hand when doing optimization, whereas compiled languages won't. Even in cases where compiled languages do use profile feedback, it may not be representative of the current program usage.

Try writing a simple recursive Fibonacci number calculator in both C++ and Java. The Java one is faster, when using a JIT enabled JVM. Of course, that is a contrived example, but it shows that just-in-time compiling can be faster.

Re:Java is Slow

[pHDNgell]

That's a dumb benchmark. That will tell you that the program *starts* slow...and that, perhaps, invoking an application for each time you want to do something would be roughly the equivalent of starting a new web browser (IE on Windows doesn't count) every time you want to look at a new web page...or booting your operating system every time you want to run a program.

People don't generally write one-off small apps they intend to run hundreds of times a day in java. That's not what it's designed to do.

If you want to compare performance, do something real-like and have it run once in your two or so languages to get a base, and then run them a few thousand times. Something more like this:

http://www.bagley.org/~doug/shootout/

Re:Sure I remember...

[bnenning]

I was entering into systems administration/programming as my main job, so my code needed to run fast, lean, and mean.

Not all programs have the same requirements. In most cases developer time is much more valuable than CPU time.

Stay as close to the CPU core as possible, but far enough away to be effective. C and C++ are the only languages that accomplish this role.

Ridiculous. Most good programming techniques are independent of language. If you can't develop effectively in anything but C or C++, then your "skillz" could use some work.

Think before you code.

Yes. Think whether the performance gained by using a low-level language is actually significant, and if so whether it offsets the increased development time and greater risk of uncontrolled failures (e.g. exploitable buffer overruns).

C is a fine language, and is often necessary. But it's a premature optimization to insist on always using it because of nebulous performance concerns.

A few from C++

[Anonymous Brave Guy]

I wonder to what extent this exists in other languages?

The C++ world is full of myths about what does and doesn't enhance performance. Amongst my favourites...

1. Exceptions cripple performance.
2. Using virtual member functions cripples performance.
3. Using templates cripples performance.

In each of these cases, there is some overhead involved if you actually use the language feature, but generally not otherwise with any recent compiler. However, those overheads are usually less than hand-crafting the equivalent functionality (e.g., long jumps, function look-up tables a la C) would incur. Furthermore, if you actually understand the implications of these features, you can keep the overhead way down. The next time I see someone criticise templates for code bloat, and then demonstrate in the next post that they've never come across templated wrappers for generic base classes, I'm going to have to lecture them. }:-)

On the flip side...

1. Passing by const& always improves performance.
2. Pointer arithmetic is faster than array indexing.
3. Making things const helps the optimiser to improve performance.

Most of these get much more credit than they deserve. The first is true often, but not always: it sometimes shafts the optimiser in many compilers. The second is not true with any recent compiler. The third is true sometimes, but not nearly as often as you might expect: optimisers miss many of the apparent (to humans) possibilities anyway, and spot some of the others with or without a const there.

As always, the rule of thumb is to write correct, maintainable code first, and then to use compiler-specific, profiler-induced hackery where (and only where) required. Whether you're writing a database or a graphic engine, this is pretty much always good advice.