views:

301

answers:

5

Are there any tests that compare Javascript's performance with Java's?

UPDATE: Since everyone is asking why the hell this question, here is some context :)

As you all know - I hope - Javascript nowadays doesn't only reside in the web client but also in the web server with node.js.

It could also be run in mobile phones and dekstops with appcelerator and phonegap.

It could also be used substantially in the web browser to make the user experience first class like with desktop applications.

But Java could do these things too, running applets on the web client, and on mobile phones. It's also a language for the backend with many frameworks to choose between.

Since each one of them could almost/entirely replace each other in the mentioned area, I want to know the performance difference between them, for every case I described:

  • Client: Java Applets vs Javascript
  • Server: Java EE vs Javascript with Node.js + Express
  • Mobile phones: Java ME vs Javascript with Phonegap / Appcelerator
  • Desktop: Java SE vs Javascript with Phonegap / Appcelerator

I hope the context is more clear now.

+3  A: 

Probably not, but it doesn't really matter.

Prior to Google Chrome's JavaScript JIT, Java would win over JavaScript as soon as the problem got big enough to overcome the load time.

Java should still roundly trounce JavaScript due to integer vs. float math. No matter how good the JIT it can't really make up for this.

Joshua
PHP problem on Facebook got big enough, and then they compiled it. So...
BrunoLM
A: 

They are only similar in name, that's it. Java is compiled while JavaScript is interpreted (mostly). Even with V8's just in time compiler Java is faster at everything.

Josh K
To be fair, they are much more similar than just by name. For starters they both have a similar syntactical resemblance thanks to their use of C. Additionally, Java code can be written in JavaScript. And finally, Java ships with a JavaScript interpreter built in so you can embed JavaScript into a Java app.
Moses
Do you have any actual proof for this wild claim of "faster at everything"? Considering the extremely different fields these two languages often operate in, I'd say any attempt to say "faster" is gonna need alot more context, because I do not buy that Java is just flat out faster (at everything). Would you use Java applet for say, some lame DHTML effect that JS could do while sleeping? Is the applet faster?
Svend
@Svend: You don't benchmark languages by writing applets or specific functions. Do some abstract math, recursion, filling a Red / Black tree with 10,000 nodes, floating point calculations, string manipulation, etc. We aren't arguing the use here, we are arguing which (at the core) performs faster.
Josh K
@Josh K: When you say mostly in regards to JS, are you saying that because of stuff like GWT? When is JS not interpreted?
Esteban Araya
@Esteban Araya: *All* modern JavaScript execution engines have compilers. V8 is even a *pure* compiler, it doesn't even have an interpreter.
Jörg W Mittag
+2  A: 

Java, obviously.

Programmers love to compare execution speed like some sort of pissing content. It is just one metric, and the majority of the time, not the most important one by a long shot. Java is a language that has a mix of being fast enough for almost anything, but high enough level that you get stuff like GC, which you don't usually get in similar languages. Javascript is a dynamic closure language that is great for getting stuff done quickly (and for FP programmers stuck in an OO world ;-) ). There isn't much in the way of intersection in the spaces where either would be appropriate.

I'll stop pontificating now

EDIT: to address the edit in the post

Due to the way one writes idiomatic javascript (functions composed of functions), it lends itself surprisingly well to asynchronous programming, probably better then any other language of similar popularity. Node.js shines when it comes to a huge amount of short connections, so javascript is a really great fit for that sort of thing.

While node.js is absolutely drenched in awesome, being the new hotness really doesn't mean it is the best at everything, no matter what the hype says. If a java app is replaceable by node, chances are java wasn't really appropriate in the first place.

Matt Briggs
+4  A: 

Here are some tests comparing Javascript (V8) and compiled Java, and they indicate that Java is generally faster. However, if you dig around with that page and the linked resources, you will notice that it is very difficult to compare like with like. In particular, if you compare Javascript with "steady state" Java you will see a much more pronounced performance difference.

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.

Stephen C
igouy
>> My guess is that this is because the Javascript regex engine is faster... << With the regex-dna JavaScript V8 #2 program source code is a link to "Irregexp, Google Chrome's New Regexp Implementation" http://blog.chromium.org/2009/02/irregexp-google-chromes-new-regexp.html
igouy
+3  A: 

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.

Jörg W Mittag
Thats why I asked "How fast is Javascript compared to Java?"
never_had_a_name
>> There's a reason the call the Computer Languages Benchmark Game a "game" << There are several reasons the Computer Language Benchmarks Game is titled a "game" but you don't seem to have any special insight into what those reasons are.
igouy
>> they even encourage you right on their own page to play around with the benchmarks to make any arbitrary language rise to the top << Are you pointing to this page? http://shootout.alioth.debian.org/u32/which-language-is-best.php
igouy
>> Java and JavaScript are both programming languages. ... Programming languages aren't fast. Or slow. << True. So given the context the question is about programming language implementations not programming languages.
igouy