Why do people still say Java is slow? [closed]

Question

For a long time in SO and in other places Java has the reputation of being slow. From jokes to many comments in questions and answers, people still believe Java is slow based solely on experience with it in the 90s.

This is my issue: we have disproved (most) of the reasons that people believe Java is slow. Outside of small things, Java is pretty fast.

So why is it that people still refuse to believe Java is fast now? Is it part of their mindset that anything thats not C/C++ is slow? Is it because people don't check over time? Is it because people are just biased?

Answer 1

It's the applications. As you note, we have proved, time and time again, that in contrived scenarios Java code can meet or even beat the performance of so-called "performant" languages like C, C++, Lisp, VB6, or JavaScript. And when presented with such evidence, most sane, open-minded opponents will hang their heads in shame and promise never again to spread such slander.

...but then, they fire up Eclipse, or NetBeans, or Guiffy, or enable the Java support in their browser, or try to run an app on their favorite feature phone. And they wait for it to become responsive...

...and wait...

...and wait...



...and wait...







...and wait...











...and...




...what did I promise never to do again? Sorry, must have dozed off...

Answer 2

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was orders of magnitude slower than the C++ code.

Of course this is comparing apples with oranges. But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

Unfortunately, the benchmark data is not freely available but others have found similar numbers when comparing the overhead of runtime abstraction. For instance, Scott Meyers writes in Effective STL about the overhead of C’s generic qsort function:

C++’s sort virtually always embarrasses C’s qsort when it comes to speed. […] At runtime, sort makes inline calls to its comparison function … while qsort calls its comparison function through a pointer. […] In my tests on a vector of a million doubles, [sort] ran up to 670% faster …

Answer 3

Because it is slow... in some applications. Desktop applications have to be responsive from the beginning and the startup overhead counts as slow.

On the other hand if you run a server it does not matter if there is some heating (JIT analysis and compilation) - you do it once in blue moon so most of the time it cannot be considered entirely slow.

Answer 4

I'd say it's because when people first encountered it, it was slow. Based on that, they formed an impression of it. That impression is unlikely to change if they don't use it, and they don't use it because of that impression - it's a vicious cycle.

I must admit, I had the impression that Java was slow, and yes, that was from my previous exposure to it. I've now moved on to different languages and have had extremely limited exposure to Java since then. Consequently, my opinion hasn't changed much.

Answer 5

Because it takes a generation to change peoples perceptions about a product

It has nothing to do with how fast Java becomes. In people's minds Java is a const identifier associated with the word 'slow'. There's little, nothing you or Oracle can do about it.

Just be happy that Oracle hasn't destroyed the Java programming culture (yet) by doing anything rash or stupid. Like charging excessive licensing costs to use it. Or suing people based on software patents previously owned by Sun. ::sigh::

I hate to be the naysayer here but, unless Oracle and Google settle the Java struggle on nice terms, or Google is forced to purchase Java and makes it a 'proper' open source platform, Java is well on it's way to being the kid on the playground that has lice. IE, no one will want to touch it with a 20ft pole.

Note: Just to be clear, when I say generation I'm talking in people terms not computer terms. IE, until the people who hold that perception die of old age or replaced by a younger generation the perception will hold true. Think in terms of 5 decades not 5 years.

Answer 6

One reason is that people trust what others say instead of what they see.

According what I was told when I first started programming, Java is "slower" than C++, and reason why Java could be used is because it's "convenient and easier". It's very commonly believed that Java brings Safety and convenience, at the cost of performance. Even when later C# is invented people believe it's faster than Java because it's "native".

But the truth people see without sensing it, is that, eclipse, the IDE that's built with Java, is absolutely the FASTEST IDE in class. I've used nearly all main stream IDEs, those from MS and GNU, Borland..., eclipse is the absolute king, of IDEs, largely because of it's fast.

Another reason is its long start up time.

Java is not suitable for developing a tiny app that stay in system tray, consumes a little memory, popup a dialog reminding you to take a break; or a notepad that you use to open a text file, read it and close it. It should be used on something BIG, like a web server that's always there, make optimized use of you computing resource, respond to millions of requests every hour. Or an IDE like eclipse that manage thousands of workspace files. You don't know you Java app is fast until it has run for at least several hours, I believe.

Answer 7

@bigown "Why do people still say Java is slow?"

Because they are dumb. Because they have no work experience, but think they are the living incarnation of Dikjstra or the second coming of Linus Torvald, oh I dunno. The reasons for saying such a retarded thing are so many, but usually stupidity, mindless subjective fanboyism, and emotional attention-whoring seem to be behind them.

Let's disect this so that you can see the truth of what I've just said above:

First, what is slow, in what context, for what, under what conditions, with what engineering/scientific/business purpose (for saying tehe it sucks is not one of them.) Any person who says "X is slow" for any technology X, or simply "X is Y" where Y is some type of negative statement, without answering any of the questions above should be dismissed as a fool. Statements like that don't have a place in engineering. In politics and juvenile chat rooms maybe, but not on engineering.

Second, most of these misguided fools cry about Java being slow because ZOMG, their eclipse takes forever to fire up (gee, load the thing with all the plug ins, and guess what happens.) Most of these fools don't even know how to tune the jvm for eclipse to operate fast (or for any Java application for that matter). That is, they have no clue about performance tuning, which is a reality not just for Java, but for any non-trivial system, be it hardware or software. So right there, they disarm themselves for any technical validity in making such mindless statements.

Third, let's consider what the bulk of Java development is for: back end OLTP first and foremost; monitoring systems coming second. Either type of system is intended to run in clusters, and to run uninterrupted for weeks if not months. Does it really matter then that your little eclipse or toy app takes a minute or two to load when the purpose of REAL Java apps is to run for extended periods of time? Context, people, context.

Lastly, the backbone of OLTP on Google and Ebay run on Java. I would take that as a proof by contradiction that Java is not slow (at least for conditions that matter, not for little toy experiments, benchmarks and unverifiable annecdotal evidence done specifically for the purpose of saying "tehe X is slow, it sucks."

There is engineering, and there is fanboyism. Guess which category statements like those belong to?

Answer 8

Because it is, can we close this topic once and forever?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [scroll down to tables, Java is 3.7-12.6 times slower than C++, research by Google employees]

P.S.: If it's not, name me at least one snappy Java app for a start, haven't seen one before.

Answer 9

TMHO, this is because of the time needed to start the VM in the browser. If an application starts slowly, people will only remember that. Because, long starting time is really annoying. Really. One of my co-worker told me that he doesn't use Firefox because it is too slow. (?!?). But, Yes, Ok, on windows, Firefox takes a huge amount of time to show up. According to him, this app is slow, he made his mind about the general speed of it.

Answer 10

Slow compared to what? I'm thinking of changing from ordinary Ruby to JRuby (Java based ruby) because I've heard it's faster.

Answer 11

Opinions are opinions, and facts are facts.

Here's a fact from the Google Code Jam, which arguably challenges programmers to solve tough computing problems in a short period of time, meaning that performance of the language they use play an important role:

During the past editions (2009, 2010, 2011), around 75% of the programmers who arrived at the final rounds were using C++, as opposed to around 15% using Java.

Source -> http://www.go-hero.net/jam/

Answer 12

Circa 1997 I used a HP Vectra VE (200 MHz) and Windows 95. Most applications ran very fast on this, but then I tried a few applications written in Java (IDEs, if I recall correctly). They were very slow, at least the GUI parts of them. They took long time to start, and the GUI elements (e.g. menus) were not very responsive -- there were delays in the visual feedback. Also, since Java GUI applications had (has) a rather distinctive look, I learned to associate this look (and Java) with poor performance.

Answer 13

It depends what you means as being slow.

First of all, java as made many progress recently and is very fast in most cases. But :

• Java is slow at startup, because you have to load the JVM before doing anything.
• Some security feature can kill performances in some cases. Bound check with random access is an exemple.
• Make something really fast in java require to work against the JVM (to take advantage of cache line for exemple).
• The lack of metaprogramming imply a penality at run time with each abstraction, thus performance come to the cost of design in many cases.
• Java can hardly ensure real time constraint - by design - and this could be considered as « being slow » by some people.

By the way, java is, in some cases, faster than vanilla C/C++. But thoses languages gives you the tools to tweak them.

Java is a programming language aimed at productivity. Now it is fast enough for most applications, but isn't enough for some others.

In general, Java's slowness is an overused argument because it's irrevelant in most cases.

Answer 14

Simple, canonical Java code tends to be on par with or faster than simple, canonical C/C++/D code. Simple, canonical code tends to perform a lot of memory allocations unnecessarily, not be particularly tuned to any CPU architecture, not have tons of low level optimizations done to it, etc. Java's HotSpot GC is nothing short of amazing, and the VM optimizations tend to be better than what a static compiler could do.

On the other hand, if you really need performance and are willing to hand-tune stuff to get it, C/C++/D provides many more opportunities for this. You can't use inline assembler in Java. You can't use dirty type punning tricks to treat floating point numbers as arrays of bits. You can't use custom memory management schemes that may be faster than the GC for your specific use case. You can't allocate nearly as much on the stack in Java as in C/C++/D. In Java the only way to get anything roughly equivalent to higher order functions is with interfaces and runtime binding. In D and (I think, correct me if I'm wrong) C++, you can pass functions to templates, allowing for binding to happen at compile time without loss of flexibility.

Answer 15

Another point for "slowness" of Java is the 64bit runtime.

I've heard some people complain that Java is very slow for them on 64bit computers. As it turns out, 64bit Java runtime uses server JVM which compiles whole program before starting.

HERE is explanation why 64bit VM starts slower.

For example on Windows:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

Answer 16

The performance of Java is very subjective however, the perception of why Java is slow is largely for reasons that others have noted: most peoples perception of something is colored by their earlier experience with it and Java hasn't always been a well optimized language under the hood. Likewise, vanilla Eclipse isn't exactly a fast IDE to work with and pales in terms of responsiveness when compared to an IDE like Visual Studio.

That said though, outside of the UI issues that Java has at start-up, it is fast enough for most applications. If you search you can find articles that compare it with other languages and most of the results presented put it into the range where it will only be an issue when you are dealing with major data sets.

In the bioinformatics field it is used quite a bit because it is well supported and there is already an installation base for, one of the advantages that Java has is that you can do some fairly rapid development with it that you can't do with C. If you look at the languages used for bioinformatics (I personally use R, Python, and Java regularly) you will note that none of them is exactly the fastest and it isn't unusual for the data sets in bioinformatics to run into the 100's of gigabytes of information. At the end of the day, human time is still more valuable and while the speed differences are noticeable, the size of the data sets tend to be large enough that they run overnight anyway.

If it were easier to write a snappy UI in Java it is quite like that the speed perception would fall off the radar as most people do not push languages enough that speed is really an issue on a daily basis.

Answer 17

To throw in a worthless coin, I find that Java webapps generally have long startup and response times, where it seems to me that Python or Ruby would have done better.

I do use Eclipse for most of my programming, and I must say that Java is just as fast as anything else, if not faster running locally and "standalone".

Answer 18

I would say Java is infinitely slow, not just sluggish, because it fails to solve simple problems which are easy in real high level languages.

Let me give a simple example. There is a simple optimisation which applies when mapping a list twice, called deforestation: here is the rule for it written in my language Felix:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

which says: instead of mapping list x with f, then mapping it again with g, requiring two list traversals and making a garbage temporary list, just map the list with the composition of the functions.

This is a high level optimisation vastly more significant than low level performance of the Java JVM. The specification I gave above isn't just pretty syntax, this is an instruction written by the user telling the Felix compiler how to perform an optimisation.

Please show me how to do this kind of thing in Java. No? Then Java is slow. Very slow. [Haskell can do this one automatically I believe].

And before you say "but Java is an OO language, this kind of optimisation doesn't apply" .. well that's exactly my point. Java sucks, and being OO is one of the main reasons.

JIT optimisation can never come even close to competing with the kinds of optimisations a decent compiler can do.