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?

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Mark Trapp Oct 5 '11 at 15:49

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

18 Answers
18

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...

I never thought Javascript was considered a "performant" language.
–
zneakOct 2 '10 at 18:38

56

I have issues with this. Firefox is written mainly in C++ and its slow. Does that mean C++ is slow? No, it means Firefox is slow. Saying that a language is slow because the largest program written in it is slow is stupid.
–
TheLQOct 23 '10 at 19:15

13

Jonas, using the simplest example I can find doesn't make me a bad programmer. If you've got a magic method that runs a Java GUI in less than a blink, go ahead and demonstrate it.
–
Peter BoughtonOct 25 '10 at 9:01

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 …

To be fair, std::sort is one of the cases where it's difficult to do anything similar in other languages. But the vast majority of projects I've seen aren't writing std::sort -like code. They are writing (bad) Java code in C++, and complaining that they have problems.
–
Billy ONealOct 22 '10 at 16:23

2

Do you have any reports to backup your story that huge datasets are slow? I've heard people talking about doing operations 1-2 million entry Lists and it still being fast. And isn't messing with massive datasets in memory (usually stuff like that is in a DB) a bit of a niche field?
–
TheLQOct 23 '10 at 19:11

8

@TheLQ: the source is the SeqAn book by Gogol-Döring & Reinert. And about your counter-example: what operations? And what do they consider “fast”? Also, 1E6 entries isn’t all that large. ;-) And as to whether this is a niche field – certainly. But this is where you need fast computations. The point is whether Java is fast, not whether it’s “fast enough” for inexpensive operations. On a small enough data set, everything is fast enough.
–
Konrad RudolphOct 24 '10 at 10:51

2

there is no such thing as best possible implementation
–
fonzoOct 5 '11 at 12:16

3

@fonzo There can be reasonable approximations. Scratch that, for a simple enough algorithm and a well-defined metric there can be a best possible implementation. This is the case here. The algorithm is simple, and there is a well-defined case for which was optimised: running time on a given input.
–
Konrad RudolphOct 5 '11 at 12:22

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.

And how do I tweak those command line switches to avoid by entire browser locking up for 5 seconds if I click on a link that contains a Java thing? That is the kind of thing that makes people call Java slow, and it doesn't matter that once loaded it actually runs rather quickly.
–
romkynsJan 22 '11 at 12:03

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.

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.

I think Google is using so much Java that them buying it is not an entirely unfeasible theory. I'd probably be happy with it.
–
Bart van HeukelomSep 14 '10 at 22:15

1

@donroby: And who cares about these languages? In two decades Java will going to be a niche language.
–
aascOct 22 '10 at 22:44

1

@aasc - Java might be obsolete in two decades, but LISP isn't now and won't be then.
–
Don RobyOct 23 '10 at 2:53

2

@aasc "Programmings languages usually don't live more than a generation" Good lord man, 1 million Delphi Developers that's Pascal, 5 Million Visual Basic Developers err... not to mention Perl, Lisp, Fortran, Cobol, C++ do you have any justification for that comment???
–
ReallyethicalOct 24 '10 at 14:01

2

@Reallyethical Not in the mainstream. How many businesses depend on Lisp, Fortran, Cobol. With lisp, it's mostly trapped in academia and used as a model for features of other languages, few use it for actual production projects. Fortran has become a niche language for high performance mathematical modeling and Cobol only remains because the banking industry is to damn scared to change their old/dependable code to a new platform. C++ is the glaring exception because it is still very widely used and adopted today.
–
Evan PlaiceNov 11 '10 at 0:24

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.

@finnw - it is if you tune it. Out of the box and with all the plug ins, obviously it won't be fast. Obviously it can never be compared to vim or jedit or Notepad++, but these "fast" or "slow" arguments and statements are meaningless without a context.
–
luis.espinalOct 13 '10 at 11:21

2

@luis you can however compare it to Delphi 7, which I don't believe is all that much simpler than Eclipse. And Delphi 7 is almost as fast as notepad. It's insane.
–
romkynsJan 22 '11 at 12:07

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?

If I have to tune my JVM to get Java to run acceptably fast, while I don't have to tune anything (except -O2) to get C++ to run acceptably fast, then Java is slow.
–
David ThornleyOct 22 '10 at 17:50

5

@luis.espinal: I was responding to your reason #2: that people say Java is slow because, in your opinion, they have failed to tune Java. Please also note my use of "acceptably fast". It would seem to me that something that is not "acceptably fast" is slow, and it would seem to me that something people routinely claim is slow is likely not acceptably fast.
–
David ThornleyOct 25 '10 at 13:50

4

@luis espinal You sound like Kant :) People here have made an implicit assumption that slow means slower in comparison to other practical, production-ready languages like C++. (Remember physics??) when you measure potential energy, you always measure it relative to some ground. Now going by your grammar, "X is dumb" is baseless. and "X is dumber than Knuth" does not make X an absolute dumb, as pretty much anyone can be X here. I agree calling a lang slow is not elite, but the people here who say that are not "dumb", but just happen to have made an agreed upon implicit assumption.
–
yati sagadeOct 5 '11 at 13:37

1

@luis hahaa.. nice observation. (My belief that you're a reincarnation of Kant has become even more solid ;) ) And such discussions end up in flame wars and unproductive keystrokes... According to me, one should always stick to what seems like the best tool to tackle the job at hand. Agree, Kant2 ? :P
–
yati sagadeOct 5 '11 at 14:07

This paper is very far from scientific research standards. It doesn't even compare exactly the same algorithms and optimizations in all the languages. "E. Java Tunings Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well." jeremymanson.blogspot.com/2011/06/scala-java-shootout.html
–
Piotr KolaczkowskiNov 4 '13 at 15:09

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.

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.

That only really proves that Java can make it to the top of a speed-focused competition but most people choose C++.
–
Anna Lear♦Oct 5 '11 at 13:27

3

"solve tough computing problems in a short period of time" -- what, the time it takes to write the code, or the time it takes to run the code? Regardless, your fact is that -- a fact -- what does that have to do with the question? Are you drawing a conclusion from your fact?
–
occulusJan 8 '12 at 19:36

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.

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.

The server VM is slower to start-up but it does not natively compile the whole program before starting. It couldn't, classes are loaded lazily and potentially via reflection, so there is no way to know in advance what bytecode would need to be natively compiled.
–
Dan DyerSep 11 '10 at 13:11

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.

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.

I have absolutely no idea what your code does there. And if you say that an entire language is slow just because it can't do one small optimization then there are other problems here
–
TheLQJan 22 '11 at 16:34

7

-1 digging up an old question and bashing a language with very lame arguments. Tell me if you want a detailed writeup about what's wrong with your reasoning. For starters, naming OO as the main reason it sucks is not very objective and the de facto performance of a JVM+JIT is very good, even if there are optimizations left out.
–
delnanJan 22 '11 at 17:11

8

Haskell is infinitely slower than Java for our main platform, because it is not ported to said platform, so Haskell sucks...
–
user1249Feb 7 '11 at 19:32

1

@Thorbjørn Ravn Andersen I really wish I could give you a +1 for that observation.
–
Patrick HughesJul 16 '11 at 3:01