If you are doing a lot of processing on numeric arrays, then no, Java is certainly not one of the faster languages. Its very difficult to have safety (for example no out of bounds dereferencing of arrays) and performance. (An extremely interesting language that tries to do that is ATS <a href="http://en.wikipedia.org/wiki/ATS_%28programming_language%29" rel="nofollow">http://en.wikipedia.org/wiki/ATS_%28programming_language%29</a>)<p>Yes in theory Java will elliminate most of those checks, but difference between theory and practice is more than what theory would suggest.<p>For simple loops for (i==; i < n; ++i) where n is a compile time constant (or something that can be proved to be a constant) this would work. But one encounters a lot of loops where n isnt a constant. This is just one example of what slows Java down, there are others. It overspecifies semantics (think order of evaluation of arguments), gaining safety but losing on performance.<p>That said I think the JVM is one of the best optimized runtime that we have. Overall JVM is a great platform, but Java is not necessarily the best way to exploit it. Coming back to Java performance, in my experience it would get to around 80% of the speed of a C or C++ code but would use 3~4 times the memory. No careful benchmarking this, just anecdotal experience.<p>JVM developers, in case you are reading this, please add tail call ellimination and SIMD.<p>I am not a "3 cheers for dynamically typed languages" person, but for Java I am willing to concede that the type system comes with the drawbacks but little benefit. In C++, and D you can pull the gloves off when required. And please dont get me started on JINI.<p>A problem is that Java based systems are slow both in the big (I am looking at you Hadoop) and the small. You can run some of the C++ based mapreduce implementations (<a href="http://sector.sourceforge.net/" rel="nofollow">http://sector.sourceforge.net/</a>) and draw your own conclusion.
Because Java set itself up for failure. Java _can_ theoretically be faster than optimized C code, but the problem is that people over-promised and/or believe this would be the common case. Sun/Oracle failed to deliver a JIT that outperformed optimized C code in the common case.<p>Java also messed up and was too preoccupied on getting faster throughput (in too specialized circumstances) and didn't focus much on latency/user-responsiveness.<p>End users don't care about theory. The only care about their individual user experience. When they see slow launch times, long unresponsive pauses (due to garbage collection), and similar apps written in native languages running faster and being more responsive as a general trend, people are going to rightly blame Java.
I don't think people who really know what they're talking about say that. Sure the JVM is slow to start so there's latency involved in getting Java up and going, but Java is very fast over the long term.
One of my theories on why Java feels so doggone slow on GUI apps is that it refuses to use native platform APIs for anything. Everything must be reimplemented in Java. So Java manages to feel more sluggish than python, which has a slower interpreter, but isn't bound by doctrine to reimplement the entire UI toolkit in pure python.<p>That, and I think Java has huge internal libraries, full of redundancy, that get recompiled on every run, because nothing gets done without them.<p>The fundamental problem is that Java can't decide whether it wants to be a low level or high level language. It tries to be both at once, and one casualty is performance.
Admittedly I don't have that much experience in Java but have worked on C++ systems with sub 10us latency (and it did fairly complex things). Any memory allocation can take an order of magnitude more time than that.<p>Apart from writing your own memory arena, you would need to put local objects on the heap in Java. It is possible to write high performance Java, but like a previous comment mentioned, that code looks more and more like C++, so why not just write C++?
Because that is what someone/blog/article told them one time (or less commonly they remember 1998 Java performance). Java is one of the faster languages out there and has been since 1.4+: <a href="http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=all&data=u64q" rel="nofollow">http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...</a>
I recently went back to an old Java app to benchmark it against some new code.<p>For small command line utilities the startup overhead can be massive compared to the actual running time of the program, even if the <insert algorithm> runs 100ms faster in Java compared to C/C++/Go/<insert other> it won't matter if the startup time takes 400ms longer.
The problem with Java isn't being slow. Look JavaScript is the fastest growing language in usage lately and is much slower than Java. What is the problem than? The community (sorry just my opinion). Where is the npm (maven? c'mon something good please) for Java where I can find plug-in-play modules for my applications? Where are the exciting web frameworks for Java like Express/Rails/Laravel (ok we have play... but still). How many times I've heard something exciting about Java here on HN? 1...2... never mind.<p>Stop being a secret society (sorry again) type of community and start putting more projects on Github (that are easy to use and get started with), writing more tutorials on visible places, being more active.<p>I am sure I will hurt some feelings here. Get easy on the comments ;)
Seems to me that the only time I hear that Java is slow anymore is when I read someone asking "Why do people still say Java is slow," and the like.<p>Do people still say Java is slow?
Because it is? There are some circumstances where the slow-down is minimal or at least inconsequential, but not always. JIT-delay is a real thing, and even though in some applications the impact can be minimized (e.g. services) in others it's not. There's a reason why it's still very rare for games to be written in java, for example, and it's not because of blind prejudice.