61

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?

Community
  • 1
TheLQ
  • 13,478
  • 7
  • 55
  • 87

18 Answers18

131

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

Shog9
  • 8,083
  • 2
  • 45
  • 56
  • 1
    Applications like NetBeans or Eclipse are large by themselves. I've seen similarly huge startup times with other large programs, although it was just a *tiny* bit faster. But a tiny bit does not yield a language slow – TheLQ Sep 02 '10 at 11:02
  • 44
    Even the simplest Java GUI takes at least 1.5 seconds to start. That's not a tiny bit. – Peter Boughton Sep 02 '10 at 17:44
  • 2
    This is true. I wrote a *small* Swing program years ago (2005ish). It too was slow. :-/ – Paul Nathan Sep 07 '10 at 16:08
  • 1
    @TheLQ it's not just start up time with eclipse and things like it, it's also the GC bloat – Spudd86 Sep 09 '10 at 18:10
  • 2
    @Peter: That's faster than my Native Windows GUI! Is it? xD – Tamara Wijsman Sep 11 '10 at 13:16
  • 2
    TomWij, stop running Vista on a 486 then. If a simple dialog+text doesn't display before you can blink, there's something wrong. – Peter Boughton Sep 12 '10 at 19:50
  • 7
    Eclipse is faster than Photoshop or Flash. For small applications, the startup time of the JVM may be a hindrance, but how many of such small apps do you really use? – Bart van Heukelom Sep 14 '10 at 22:08
  • 32
    I never thought Javascript was considered a "performant" language. – zneak Oct 02 '10 at 18:38
  • 2
    @user813: "GC bloat" may have been an issue 10 years ago, but nowadays it's definitely a myth. Use a profiler to see how much resources the garbage collector uses in e.g. Eclipse, and you'll see that it's pretty much << 1 % of the total CPU usage virtually all the time. – Joonas Pulakka Oct 13 '10 at 11:59
  • 11
    +1 for mentioning IDEs. There's a huge difference between the responsiveness of Eclipse and an IDE like Visual Studio. – mellowsoon Oct 22 '10 at 17:50
  • 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. – TheLQ Oct 23 '10 at 19:15
  • 2
    @Peter: That's wrong. You must be a bad programmer if your Java Swing app takes that long to start. I can write a simple Java Swing application that starts blistering fast, much much faster than a second. Maybe it's years since you used a small Swing application. – Jonas Oct 25 '10 at 01: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](http://stackoverflow.com/questions/508723/fastest-way-to-create-a-java-message-dialog-swing-awt-other). – Peter Boughton Oct 25 '10 at 09:01
  • @mellowsoon: I used to work with both VS and Eclipse, and you're right, Eclipse was much faster, but it only took longer to start. Just in case (:D) you meant the opposite: Maybe my VS version was too old my configuration untypical. – maaartinus Oct 05 '11 at 14:12
  • 2
    @TheLQ: firefox isnt slow BUT if you write a GUI hello world in java and another in python and the python one executes faster then........ really what can you say? Someone wrote hello world wrong? –  Oct 05 '11 at 20:03
  • 2
    @acidzombie24 Try building a server over C++/C# or whatever language you could find HECK try building it with C and THEN compare against JAVA. The thing with C is that it's fast if you're a "Ma, i wrote 10 lines C code that is faster then Java but you can't read it" type of guy. The moment when your C code grows, your speed slows ;) – AceofSpades Jan 03 '12 at 18:42
  • 5
    It's not just desktop or mobile. Server applications are mind-numbingly slow too. Just compare restarting Tomcat to restarting any other application server written in any other dynamic language. And let's not put the blame on Tomcat itself, since it's by far the most used, optimized and lightweight web application server in the Java world. And let's not start on memory usage. – Tobia Mar 15 '13 at 09:16
48

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 …

Konrad Rudolph
  • 13,059
  • 4
  • 55
  • 75
  • 6
    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 ONeal Oct 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? – TheLQ Oct 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 Rudolph Oct 24 '10 at 10:51
  • did said former colleague publish his findings? –  Feb 07 '11 at 19:24
  • @ThorbjørnRavnAndersen Yes, see my previous comment. But I’ve found a much better (because less problem specific) reference in the meantime: Scott Meyers reports a 670% speedup for `sort` compared to `qsort` in *Effective STL* when sorting a vector of a million `double` s. – Konrad Rudolph Feb 07 '11 at 20:04
  • @KonradRudolph, is this available online? –  Oct 05 '11 at 11:26
  • @ThorbjørnRavnAndersen Not free, that I’m aware of. You can [buy the ebook](http://www.crcpress.com/ecommerce_product/product_detail.jsf?isbn=9781420076233), and there’s a limited preview but searching for “benchmark” or “Java” didn’t turn up anything of interest. But to repeat my last comment, the benchmark from Meyers is less problematic because the reference is easier to find and personally I find the numbers more credible: the “400 times” should more likely be “400%” (but I was definitely given the number as “400 times”). Anyway, I will change my answer to use the Meyers number. – Konrad Rudolph Oct 05 '11 at 11:59
  • @KonradRudolph I do not doubt the findings. Just interested in seeing the original presentations. –  Oct 05 '11 at 12:13
  • 2
    there is no such thing as *best possible implementation* – jeremy-george Oct 05 '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 Rudolph Oct 05 '11 at 12:22
  • Don't remember the last time I needed to sort. Clearly "where it counts" is domain specific rather than universal. I remember when "C" was considered slow: all the best programmers used assembly. C++ can do some great things, but I've not had the pleasure of working on a team of 20 where the build times were less than forty minutes. With Java and Ruby I'm patching code on the fly. I still write some C++, and I play with LLVM, but my day job is Java because like "C" twenty years ago, its not soooo slow that its speed outweighs its benefits. Havent written any assembly for years. – jamie May 02 '13 at 05:11
  • @jamie You don’t remember the last time you needed to sort? You gotta be kidding. Almost every nontrivial application needs it *somewhere*. And “where it counts” is the only relevant metric, isn’t it? If speed isn’t important then of course using a slower language is fine – that seems obvious. The comparison is really a red herring because unlike assembly (and unlike C!) C++ allows very high level abstractions (which, unlike in Java, often come at no runtime cost). – Konrad Rudolph May 02 '13 at 07:05
  • @Konrad My application uses sort regularly, but it happens in the database. The point is that if something you do is really critical, somebody has probably already figured out a truly optimal solution. On the other hand, I have on numerous occasions seen developers waste time getting themselves off writing "optimal" solutions that completely miss either (a) someone much smarter than them has written a library to do it or (b) there is a much better algorithm or access strategy that would render their solution pointless. Or both. So, no, I do not remember the last time I had to sort. – jamie May 02 '13 at 15:25
  • 1
    @jamie In other words, you do sort all the time, you just don’t write the function yourself. My point precisely. C++ makes it possible to write highly generic, reusable libraries that have zero runtime overhead – case in point, `sort`. `Sort` in Java is written by smart developers as you noted, but to achieve optimal performance (at least for built-in types) they had to copy-paste the code all over, rather than being able to implement the method only once for all types (and maybe overloading for interesting special cases). – Konrad Rudolph May 02 '13 at 16:22
  • @Konrad You miss my point. There is not a single call to sort in our entire Java code base. I don't care if its implemented with cut-and-paste. We don't use it. For us, "where it counts" is "how fast can you implement this new feature so we can win this new customer worth $$$$". Java is faster "where it counts" *for us*. In *your* definition of where it counts, "computationally heavy data sets", you are correct. Two different domains, two different answers. – jamie May 02 '13 at 17:53
  • 1
    @jamie I agree with that assessment. But you are distorting OP’s question: it was exclusively about runtime performance. And I rather suspect that the answer “it’s fast enough if you don’t require top performance” wouldn’t satisfy the OP. – Konrad Rudolph May 02 '13 at 18:32
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/8582/discussion-between-jamie-and-konrad-rudolph) – jamie May 02 '13 at 18:53
28

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.

Michael K
  • 15,539
  • 9
  • 61
  • 93
Maciej Piechotka
  • 2,465
  • 2
  • 18
  • 19
  • Startup costs are a problem, but you can tweak it with some command line switches – TheLQ Sep 02 '10 at 11:02
  • 22
    How many users actually know about command line switches? – Walter Sep 02 '10 at 11:41
  • 17
    TheLQ, if you can provide a command line switch to remove the 1.5s startup delay for Swing/AWT, please go ahead and answer this: http://stackoverflow.com/questions/508723/fastest-way-to-create-a-java-message-dialog-swing-awt-other – Peter Boughton Sep 02 '10 at 17:47
  • 6
    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. – Roman Starkov Jan 22 '11 at 12:03
21

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.

Damovisa
  • 1,975
  • 3
  • 20
  • 23
  • 3
    +1 -- I totally agree. I hated Java in its early days. The .NET Framework really helped the managed code cause: I liked C# and eventually I appreciated Java, too. – Wizard79 Sep 07 '10 at 10:28
  • 7
    It still takes over a second to run hello world. It's slow in terms of startup time. – intuited Sep 21 '10 at 05:19
  • @intuited Try building a server over C++/C# or whatever language you could find HECK try building it with C and THEN compare against JAVA. The thing with C is that it's fast if you're a "Ma, i wrote 10 lines C code that is faster then Java but you can't read it" type of guy. The moment when your C code grows, your speed slows ;) – AceofSpades Jan 03 '12 at 18:43
16

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.

Evan Plaice
  • 5,725
  • 2
  • 24
  • 34
  • 2
    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 Heukelom Sep 14 '10 at 22:15
  • @Bart In the right hands and with a rebranding, Java still has a chance. I just wouldn't consider Oracle to be the right hands. Personally, I am a C# fanboy but there's always that paranoia that MS might do something diabolical when their "we're not gonna screw you" policy expires in 2012. – Evan Plaice Sep 15 '10 at 11:39
  • Programmings languages usually don't live more than a generation, so Java will be considered fast when nobody cares. – aasc Sep 18 '10 at 09:51
  • @aasc - "Programmings languages usually don't live more than a generation" - ???? LISP, FORTRAN, COBOL are all alive and quite old. – Don Roby Oct 22 '10 at 15:44
  • 1
    @donroby: And who cares about these languages? In two decades Java will going to be a niche language. – aasc Oct 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 Roby Oct 23 '10 at 02: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??? – Reallyethical Oct 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 Plaice Nov 11 '10 at 00:24
  • Languages live and die based on whose learning them. Delphi is a prime. Who wants to waste their time learning it. Back when pascal was the standard language for teaching in universities it was a great choice but Borland got greedy and didn't create a cheap alternative set of tools for students to adopt it. Because of this (and the fact that students are poor) Java and C# became the primary OOP languages for teaching in universities. Delphi will die with the generation that learned it in school. – Evan Plaice Nov 11 '10 at 00:27
  • 1
    Java has a pretty bad image in the mainstream and the alternatives are gaining traction. All it takes is one mistake (borland charging students too much for their IDE) to effectively kill a language. Even if it takes a generation of programmers dying of old age to kill it. – Evan Plaice Nov 11 '10 at 00:30
  • @Don : How many commercial Applications use LISP ? – Geek Nov 11 '10 at 07:18
  • 1
    I cannot believe nobody has mentioned RPG. RPG and COBOL are the backbone of all things financial in the US today. People write new apps in .Net or Java, but they usually just feed data to the old COBOL/RPG stuff that everyone is afraid to touch. – Morgan Herlocker Oct 05 '11 at 13:10
  • Norton AV was dead slow once and ate memory like anything. I know people who still refuse to go near Norton when actually its the fastest I know today. – nawfal Apr 02 '13 at 23:45
  • @nawfal most people I know (including myself) who won't touch Norton with a 10 foot pole are that way not because it's slow but because it's (or used to be) spyware. – jwenting Apr 10 '13 at 06:12
  • @jwenting most ppl I know do not use the same pole for the reason I mentioned. Different localities :) Not to mean that Java is fast or slow (it's all relative) – nawfal Apr 10 '13 at 10:08
11

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.

tactoth
  • 543
  • 1
  • 3
  • 12
  • Indeed, a common side-effect of many JIT compilers is that programs - and individual code paths *within* those programs - are rather sluggish the first time through. Which is bad news for interactive software with lots of different code paths, and especially in little one-pass utility programs. – Shog9 Sep 18 '10 at 04:40
  • 1
    Isee slowness all the time. – aasc Sep 18 '10 at 09:52
  • 28
    Eclipse fast? LMAO – finnw Sep 18 '10 at 15:48
  • 2
    @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.espinal Oct 13 '10 at 11:21
  • +1000 for "One reason is that people trust what others say instead of what they see.". – Geek Nov 11 '10 at 07:16
  • 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. – Roman Starkov Jan 22 '11 at 12:07
  • @romkyns - I haven't touched Delphi since 1995 so I have no clue what state of being it is nowadays. If Delphi (as it was then) written natively (as opposed to Java) and if does not implement a plugable architecture (as opposed to Eclipse), then it is still *not* an apples-n-oranges comparison. The *context* I'm referring to is that Eclipse is a pluggable platform - the IDE simply sits on top of it (so Eclipse itself is more than IDE.) And I can configure that platform to launch in about 20 seconds (fast in *that context*). – luis.espinal Jan 26 '11 at 02:47
  • 1
    @romkyns - con't - so if Delphi is *functionally equivalent* to, and incurs the same interpretation/VM overhead as Eclipse, AND still loads as fast as Notepad, then *1)* my hats off to Delphi's developers and *2)* my original argument is wrong. But that's only if *that's* the context that give such comparisons meaning. WRT to engineering-acceptable performance comparisons, *context* is king. – luis.espinal Jan 26 '11 at 02:50
  • @luis Agreed, apples to oranges then. – Roman Starkov Jan 26 '11 at 12:39
  • 4
    @finnw, for an IDE with zillions of plugin it's pretty fast :) –  Feb 07 '11 at 19:24
  • @luis.espinal - You shouldn't have to tune a vanilla IDE for performance, it should come that way when install it. If you look at Visual Studio, it's usually the plug-ins that slow things down. – rjzii Oct 05 '11 at 12:45
  • I've had the opposite experience with Eclipse. For me both the start-up and run-time are very slow. The issue may have more to do with the JVM implementation than the Java language. – mike30 Nov 15 '12 at 21:33
  • Eclipse is faster than Visual Studio. But it all depends on versions. VS6 was faster than Eclipse 1, VS2005 was much slower than Eclipse 2, VS2010 is still slower than Eclipse 3, but has improved performance more than has Eclipse in between versions. – jwenting Apr 10 '13 at 06:14
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.

Coder
  • 6,958
  • 5
  • 37
  • 49
  • 6
    Please summarize the contents of the PDF in your answer. – Adam Lear Oct 05 '11 at 15:06
  • 1
    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." http://jeremymanson.blogspot.com/2011/06/scala-java-shootout.html – Piotr Kolaczkowski Nov 04 '13 at 15:09
8

@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?

luis.espinal
  • 2,560
  • 1
  • 20
  • 17
  • 19
    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 Thornley Oct 22 '10 at 17:50
  • @David - Obvious statement. Anyone knows that Java is slower than C++. That does not logically follow that it is slow, however. Neither mentioning of gcc flags give the comment validity. It only states that `it is slower than something else.` A jaguar is slower than a cheetah. Does that make the former `slow`? Try some engineering objectivity and ask yourself this: can one logically declare, `arbitrarily`, that something is `slow` simply because `it is slower` than something else `without mentioning a context of operations` that defines what is `fast enough` and for what? Can you, logically? – luis.espinal Oct 22 '10 at 19:46
  • 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 Thornley Oct 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 sagade Oct 05 '11 at 13:37
  • @yati - hahaha as per the Kantian comparison, an implicit assumption was done without direct experience of the subject ;) I must admit that using the word "dumb" is incendiary. However, "X is dumber than Knuth" only describes dumbness wrt to Knuth's brilliance, and does not describe something intrinsic of X (say *"X has done an act that is truly dumb"*). I do believe, perhaps unfortunately, that we engineers should hold ourselves to better standards and avoid implicit assumptions on things that are complex, measurable and (already) well-documented. Java technology fits these three :/ – luis.espinal Oct 05 '11 at 13:59
  • 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 sagade Oct 05 '11 at 14:07
  • I've been compared to Nietzsche, but never to Kant. It's a first :) To me, making implicit judgements on a technical subject without basis, and in particular, on a subject that has already been very well characterized and documented by academia and industry for the last 15 or so years, well..., it's dumb. We are in the business of making software, and we walk a thin line between science and engineering. That calls for a higher standard of thinking with little to no room for unsubstantiated implicit assumptions of that which is already quantifiable. I would like to think this is the way to go:) – luis.espinal Oct 05 '11 at 14:08
6

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/

Daniel Scocco
  • 5,832
  • 9
  • 39
  • 47
  • 3
    That only really proves that Java *can* make it to the top of a speed-focused competition but most people choose C++. – Adam Lear Oct 05 '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? – occulus Jan 08 '12 at 19:36
  • which may just be because 75% of people writing programs that make the final rounds think Java is slow without ever having tested it and therefore use C++ instead because they believe it is fast without ever having tested it. – jwenting Apr 10 '13 at 06:15
6

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

Andrew Grimm
  • 526
  • 3
  • 14
6

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.

Rabskatran
  • 1,421
  • 1
  • 14
  • 20
  • That's why Mozilla has been spending an awful lot of effort to get Firefox to start fast... – Spudd86 Sep 09 '10 at 18:12
  • 2
    It might turn out like Windows. Yes, after you log in you see the desktop really quickly, but then you still have to wait a while for it to get responsive. – Bart van Heukelom Sep 14 '10 at 22:16
4

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.

deadalnix
  • 5,973
  • 2
  • 31
  • 27
4

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.

Andreas Rejbrand
  • 1,791
  • 1
  • 10
  • 7
2

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.

dsimcha
  • 17,224
  • 9
  • 64
  • 81
  • 5
    Can you source those comments? I.e. where are any benchmarks showing canonical code in each language showing Java being faster? – Billy ONeal Oct 22 '10 at 16:11
1

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)
Community
  • 1
AndrejaKo
  • 573
  • 4
  • 12
  • 3
    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 Dyer Sep 11 '10 at 13:11
  • @Dan Dyer After some research, looks like I misunderstood what I read. I meant that Server VM does more optimization while client is optimized for quick start and smaller memory use. – AndrejaKo Sep 11 '10 at 14:42
  • server VM is optimised for long running processes, therefore preloads more which leads to longer startup times and tends to use more RAM. Client VM is optimised for lower footprint and startup times, but may have lower runtime performance. – jwenting Apr 10 '13 at 06:18
0

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.

rjzii
  • 11,274
  • 6
  • 46
  • 71
0

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

Undo
  • 103
  • 8
-7

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.

Yttrill
  • 727
  • 5
  • 10
  • 3
    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 – TheLQ Jan 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. –  Jan 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... –  Feb 07 '11 at 19:32
  • 1
    @Thorbjørn Ravn Andersen I really wish I could give you a +1 for that observation. – Patrick Hughes Jul 16 '11 at 03:01