How fast is Javascript compared to Java? [closed]
Java and JavaScript are both programming languages. Programming languages are just a bunch of abstract mathematical rules. Programming languages aren't fast. Or slow. They just are.
The performance of an application has nothing to do with the language. The most important factor is the application architecture. Then comes algorithmic efficiency. Then micro-optimizations. Then comes the quality of the compiler/interpreter. Then the CPU. Maybe a couple of other steps in between. The language, however, doesn't directly play a role. (And of course if you're talking about benchmarks, then also the particular benchmark plays a role, as well as how well implemented the benchmark is, how well run it is, whether the guy who performs the benchmark actually knows something about benchmarking, and even more importantly statistics. Also, the precise definition of what you actually mean by "fast" is pretty important, since it can also have significant influence on the benchmark.)
However, the language might indirectly play a role: it is much easier to find and fix performance bottlenecks in 10 lines of highly expressive, clear, concise, readable, well-factored, isolated, high-level Lisp code, than in 100 lines of tangled, low-level C. (Note that those two languages are only examples. I don't mean to single any one language out.) Twitter, for example, have said that with a less expressive language than Ruby, they wouldn't have been able to make such radical changes to their architecture in such a short amount of time, to fix their scalability problems. And the reason why Node.js is able to provide such good evented I/O performance is because JavaScript's standard library is so crappy. (That way, Node.js has to provide all I/O itself, so they can optimize it for evented I/O from the ground up. Ruby and Python, for example, have evented I/O libraries that work just as well as Node.js and are much more mature ... but, Ruby and Python already have large standard libraries, including I/O libraries, all of which are synchronous and don't play well with evented libraries. JavaScript doesn't have the problem of I/O libraries that don't play well with evented I/O, because JavaScript doesn't have I/O libraries at all.)
But if you really want to compare the two, here's an interesting datapoint for you: HotSpot, which is one of the more popular, and also more performant JVM implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, HotSpot didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.
V8, which is one of the more popular, and also more performant JavaScript implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, V8 didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.
Given that the two are more or less the same, we can expect similar performance. The only difference is that HotSpot has over a hundred engineers working on it for 15 years, whereas V8 has a dozen engineers working for less than 5 years. That is the only difference in performance. It's not about static vs. dynamic typing (Java is statically typed, but most JVMs and certainly HotSpot make no static optimizations whatsoever, all optimizations are purely dynamic), compilation vs. interpretation (HotSpot is actually interpreted with an additional JIT compiler, whereas V8 is purely compiled), high-level vs. low-level. It is purely about money.
But I am going to bet that for every pair of Java and JavaScript implementations where the Java implementation is faster, I can find another pair where the JavaScript implementation is faster. Also, I can probably keep the pair and just use a different benchmark. There's a reason the call the Computer Languages Benchmark Game a "game": they even encourage you right on their own page to play around with the benchmarks to make any arbitrary language rise to the top.
I only have an anecdote to add: I've recently reimplemented a Java calc server (finance) in Javascript (nodejs v0.6.8). WRT development time, the Javascript implementation was a breeze compared to the original Java implementation with far fewer lines of code. It was a breath of fresh air, really.
The Javascript-based server is able to calc through 2.4k trades/sec whereas the Java server handles 400+/sec on the same hardware using less memory. I wouldn't attribute the speed increase to raw V8 vs. Java 7 performance but rather to the implementation. The Javascript implementation uses far fewer data structures, does an order of magnitude fewer method calls and takes a more straight-forward and terse approach.
Needless to say, I'm very happy with the performance of node.js. And this, coming from someone who was Java only for many (9) years.
Here are some tests comparing Javascript (V8) and compiled Java:
- 32 bit
- 64 bit
They indicate that Java is generally faster1. However, if you dig around with those pages and the linked resources, you will notice that it is very difficult to compare like with like.
Interestingly, Javascript does significantly better than Java (under certain conditions) for the "regex-dna" benchmark. My guess is that this is because the Javascript regex engine is faster than the Java regex engine. This is not entirely unsurprising, given the importance of regexes in typical Javascript applications.
1 - Strictly speaking, you cannot say that language X is faster than language Y. You can only compare specific implementations of the respective languages. And the site I linked to is clear about that ... if you care to go in via the front page. However it is not entirely unreasonable to generalize from specific datapoints ... and the apparent of absence of contradictory datapoints ... that Java is typically faster than Javascript in computationally intensive tasks. But the flip side is that that kind of performance is often not an objectively important criterion.