Is Java really slow?

Answer 1

Java is definitely slow, especially for quantitative work.

I use a combination of R, Python and C/C++ with optimised multithreaded ATLAS libraries. In each of these languages I can matrix multiply a 3000 by 3000 matrix of doubles with itself in around 4 seconds. Using Colt and Parallel Colt in Java, the same operation take 185 seconds! Astonishing despite these java libraries being parallel in nature.

So all in all, pure Java is unsuitable for quantitative work. Jblas seems to be the best linear algebra library for Java as it uses ATLAS.

My machine is an HP Core 2 Duo with 3 GB of RAM. I use 64-bit Ubuntu 10.04 (Lucid Lynx).

Answer 2

As Pascal says, Java is on par with other high-level languages. However, as someone who worked with the original JVMs on Windows 98, at the time the level of abstraction provided by the Java virtual machine was, shall we say, painful.

Basically, it was software emulation with little or no optimization that we take for granted today in the JVM.

Answer 3

It's out-dated information from the early days (mid-to-late 1990s) of Java. Every major version of Java has introduced significant speed-ups compared to the previous version. With Oracle apparently merging JRockit with Sun's JVM for Java 7, this trend looks set to continue.

Compared to many other popular modern languages (Python, Ruby, PHP), Java is actually significantly faster for most uses. It doesn't quite match C or C++ but for many tasks it's close enough. The real performance concerns ought to be about how much memory it ends up using.

Answer 4

Java WAS slow, back in the day. It has become much faster, due to a few generations of performance enhancements. Last I heard, it is usually within 10% of C# speed -- sometimes faster, sometimes slower.

Java applet startup is still slow because you've got to start a whole JVM, which has to load all it's classes. Somewhat like booting another computer. Once the JVM starts it is quite fast, but the startup is usually what people remember.

Also, there are at least a few people that will never believe in the viability of Java.

Answer 5

The main culprit in the "long startup time" is dynamic linking. A Java application consists of compiled classes. Each class references other classes (for argument types, method invocations...) by name. The JVM must examine and match those names upon startup. It does so incrementally, doing only the parts that it needs at any given time, but that is still some work to do.

In a C application, that linking phase occurs at the end of the compilation. It is slow, especially for big applications, but only the developer sees it. Linking yields an executable file which the OS simply has to load in RAM "as is".

In Java, linking occurs every single time that the application is run. Hence the long startup time.

Various optimizations have been applied, including caching techniques, and computers get faster (and they get "more faster" than applications get "more bigger"), so the problem importance has much reduced lately; but the old prejudice remains.

As for performance afterwards, my own benchmarks on compact computations with array accesses (mostly hash functions and other cryptographic algorithms) usually show that optimized C code is about 3x faster than Java code; sometimes C is only 30% faster than Java, sometimes C can be 4x faster, depending on the implemented algorithm. I saw a 10x factor when the "C" code was actually assembly for big integer arithmetics, due to the 64x64->128 multiplication opcodes that the processor offers but Java cannot use because its longest integer type is the 64-bit long. This is an edge case. Under practical conditions, I/O and memory bandwidth considerations prevent C code from being really three times faster than Java.

Answer 6

Java has the reputation of being slow because it was slow. The first versions of Java had either no or rather poor Just In Time compilation. This meant that the code, although bytecode, was being interpreted, so even for the simplest operations (like adding two integers) the machine had to do all sorts of compares and pointer dereferences and function calls. The JIT compiler has been ever-improving; now it's at the point where if I write C++ code carelessly and Java code carelessly, Java will sometimes outperform C++ because the JIT compiler realizes that I've got some unnecessary pointer dereferencing and will take care of it for me.

If you want to see just how big a difference JIT compilation makes, check out the interpreted vs. non-interpreted benchmarks at the Computer Languages Benchmark Game. (Pidigits uses an external library to do all the computations, so that benchmark doesn't change; the others show a 6-16x speedup!)

So, that's the main reason. There are a variety of other, lesser reasons that did not help matters: originally, Java startup time was slow (now fixed); web apps in Java take a long time to download (much less true now with widely accessible broadband, and with large things like movies being expected); the UI Swing was not (and still is not) written with performance in mind so it is much less snappy than equivalents in e.g. C++.