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.
"Fast" is subjective. "Fast enough for X" is better, but still subjective unless you have benchmarks. That said, I agree Java is good enough for, say, long running web-services where you take the JVM start-up hit once.
... which is useless when you're trying to develop Java code.
Java also eats a lot of RAM in many applications (J2EE apps can easily eat a few GB of RAM), so combined with the multi-second latency for startup, you're basically confined to a single programming model: One giant, long-running, multithreaded program.
Not necessarily. It "might" consume a lot of memory depending on your particular application.
We recently went live with a suite of applications (5 apps all together, both web and backend), processing tons of data in "real-time" in multiple threads and after a few days of usage someone noticed it was running with default 512M of RAM (8gb planned).
Considering the load it is processing - it is very impressive. And yes, it is using all of J2EE in WebSphere with mq, hibernate, spring core, spring integration, etc.
BUT I could not make JIRA work with 512 linode, had to upgrade to 1m and later on switch to jira-cloud as it was failing all the time.
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.
Aside from one of the most popular... Minecraft (played for days and never saw a GC pause). I think it actually is because of blind prejudice OR POSSIBLY expressiveness rather than "slowness" since most of the scripting languages within the game platforms also make use of GC systems that are much worse than the JVMs.
Umm.. Minecraft, while awesome, is certainly not one of the graphically intensive games out there, and yet the Java promise of hogging all resources available is always kept.
Minecraft is a special case because it works differently than many other games. However, it's hardly a poster boy for the awesome speed of the java platform. For one, performance (measured in fps) is highly variable on the same hardware from release to release.
As far as scripting languages used in game platforms, it's one thing to use a scripting for minor tasks within a system written in other languages, it's something else entirely to write an entire game in that language.
I'm one of those folks who suspects that projects which were written in Java might be slower that they otherwise would have been. I also bought Minecraft some time ago (back when it was roughly €7).
Having used Minecraft for a pretty long time, I don't feel like it's the sort of thing someone should hold up as exemplary of how fast Java is / can be. Instead, for me at least, it's more evidence of Java apps having troubles making use of available system resources (particularly many cores and/or larger amounts of RAM) as well as demonstrating that portability still can be a problem with Java apps (as in OpenGL v OpenGL ES; MCPC v. MCPE, MCPI & MC360; and even windows v Linux & Mac).
I get that it is possible to write Java such that certain things run pretty fast. I also don't think that these sorts of metrics should be used as the only metric every developer uses to decide what language to use for their projects. Therefore, I don't feel that these are reasons to conclude that someone else should or shouldn't use java for their project (as surely they have their own priorities which they base their own decisions on).
On the other-hand I don't think that any software programming language having advanced features which allow for efficient use of these various other system resources matters much, if many (most?, most popular?, many popular?) projects don't use them (or perhaps don't use them correctly). For that matter the same goes with hardware... it hardly matters if some chip has amazing super powers, if few projects use them.
Back to why people think Java app can be slower than they ought to be. My experience has been that when Java first began to become popular, it became the language of choice in many universities. Not long after that it was common to find poorly designed & implemented projects to be written in Java. While this has changed by now, nearly all of the Java projects, that I have experience with don't have an obvious priority of maximising performance by using all available system resources as efficiently as they can be.
Lots of people say that Minecraft has minimal requirements; but then a lot of people say that Minecraft has terrible performance because it's written in Java and 'Java is slow'.
Many of those people (both groups) are naive users who don't know much about computing or programming or games. Or they're games players so they have a different idea of what "minimal requirements" means. (A dual core 1.8 GHz processor; 3 GB ram; don't feel 'minimal' to me, but perhaps that's my age.)
It's one of the faster languages... on benchmarks. Sure you can get Java to perform close to C if its written like C, but if you've reached that point, why not just write C code?
This. Java is almost as fast as C++ safer for the average bear, and IMHO easier in the maintenance phase.
I make that last point because I think new people coming into large C++ projects often take longer to ramp up and understand the code than in large Java code bases. But that is purely anecdotal.
I recently went back to an old Java app to benchmark it against some new code.
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.
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 http://en.wikipedia.org/wiki/ATS_%28programming_language%29)
Yes in theory Java will elliminate most of those checks, but difference between theory and practice is more than what theory would suggest.
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.
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.
JVM developers, in case you are reading this, please add tail call ellimination and SIMD.
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.
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 (http://sector.sourceforge.net/) and draw your own conclusion.
> 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.
I expect you mean JNI and not Apache JINI...
That probably highlights the difference between Java and other languages you like to mention, it may use more memory and be marginally slower computationally, but when you take that the most interesting applications these days are distributed the ability to sort an array and save a few clock cycles fades into insignificance compared to network latency and connection times.
Not to mention also, you can optimize your CPU's workload or you can optimize your personal workload. Java lets you pick great libraries off the shelf. Or you can choose to manually do your own array bounds checking and pick up your own garbage.
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.
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.
I am sure I will hurt some feelings here. Get easy on the comments ;)
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.
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++?
Thank you for the link, but the benchmarks at the bottom of that page show that JTransforms is almost always slower than FFTW, and in only a few cases is it marginally faster. Benchmarks are always questionable, and I really wish they had compared single threaded performance, but I think this shows that Java still has some catching up to do before anyone should be called foolish for thinking C is faster.
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.
That, and I think Java has huge internal libraries, full of redundancy, that get recompiled on every run, because nothing gets done without them.
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.
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.
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.
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.
34 comments
[ 3.4 ms ] story [ 92.9 ms ] threadhttp://www.techempower.com/benchmarks/
Java also eats a lot of RAM in many applications (J2EE apps can easily eat a few GB of RAM), so combined with the multi-second latency for startup, you're basically confined to a single programming model: One giant, long-running, multithreaded program.
We recently went live with a suite of applications (5 apps all together, both web and backend), processing tons of data in "real-time" in multiple threads and after a few days of usage someone noticed it was running with default 512M of RAM (8gb planned).
Considering the load it is processing - it is very impressive. And yes, it is using all of J2EE in WebSphere with mq, hibernate, spring core, spring integration, etc.
BUT I could not make JIRA work with 512 linode, had to upgrade to 1m and later on switch to jira-cloud as it was failing all the time.
As far as scripting languages used in game platforms, it's one thing to use a scripting for minor tasks within a system written in other languages, it's something else entirely to write an entire game in that language.
Having used Minecraft for a pretty long time, I don't feel like it's the sort of thing someone should hold up as exemplary of how fast Java is / can be. Instead, for me at least, it's more evidence of Java apps having troubles making use of available system resources (particularly many cores and/or larger amounts of RAM) as well as demonstrating that portability still can be a problem with Java apps (as in OpenGL v OpenGL ES; MCPC v. MCPE, MCPI & MC360; and even windows v Linux & Mac).
I get that it is possible to write Java such that certain things run pretty fast. I also don't think that these sorts of metrics should be used as the only metric every developer uses to decide what language to use for their projects. Therefore, I don't feel that these are reasons to conclude that someone else should or shouldn't use java for their project (as surely they have their own priorities which they base their own decisions on).
On the other-hand I don't think that any software programming language having advanced features which allow for efficient use of these various other system resources matters much, if many (most?, most popular?, many popular?) projects don't use them (or perhaps don't use them correctly). For that matter the same goes with hardware... it hardly matters if some chip has amazing super powers, if few projects use them.
Back to why people think Java app can be slower than they ought to be. My experience has been that when Java first began to become popular, it became the language of choice in many universities. Not long after that it was common to find poorly designed & implemented projects to be written in Java. While this has changed by now, nearly all of the Java projects, that I have experience with don't have an obvious priority of maximising performance by using all available system resources as efficiently as they can be.
Lots of people say that Minecraft has minimal requirements; but then a lot of people say that Minecraft has terrible performance because it's written in Java and 'Java is slow'.
Many of those people (both groups) are naive users who don't know much about computing or programming or games. Or they're games players so they have a different idea of what "minimal requirements" means. (A dual core 1.8 GHz processor; 3 GB ram; don't feel 'minimal' to me, but perhaps that's my age.)
I make that last point because I think new people coming into large C++ projects often take longer to ramp up and understand the code than in large Java code bases. But that is purely anecdotal.
Do people still say Java is slow?
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.
Yes in theory Java will elliminate most of those checks, but difference between theory and practice is more than what theory would suggest.
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.
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.
JVM developers, in case you are reading this, please add tail call ellimination and SIMD.
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.
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 (http://sector.sourceforge.net/) and draw your own conclusion.
I expect you mean JNI and not Apache JINI...
That probably highlights the difference between Java and other languages you like to mention, it may use more memory and be marginally slower computationally, but when you take that the most interesting applications these days are distributed the ability to sort an array and save a few clock cycles fades into insignificance compared to network latency and connection times.
Not to mention also, you can optimize your CPU's workload or you can optimize your personal workload. Java lets you pick great libraries off the shelf. Or you can choose to manually do your own array bounds checking and pick up your own garbage.
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.
I am sure I will hurt some feelings here. Get easy on the comments ;)
Java devs are not too vocal on HN lists, but this is the nature of HN, which is not a fair reflection of the state of things in the industry....
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++?
That, and I think Java has huge internal libraries, full of redundancy, that get recompiled on every run, because nothing gets done without them.
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.
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.
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.