与 Java 相比，Javascript 的速度有多快？

How fast is Javascript compared to Java?

提问by never_had_a_name

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

是否有任何测试可以将 Javascript 的性能与 Java 的性能进行比较？

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.

众所周知 - 我希望 - 现在的 Javascript 不仅驻留在 Web 客户端中，而且还驻留在带有 node.js 的 Web 服务器中。

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

它也可以在带有 appcelerator 和 phonegap 的移动电话和桌面上运行。

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

它还可以在 Web 浏览器中大量使用，以使用户体验一流，就像使用桌面应用程序一样。

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.

但是 Java 也可以做这些事情，在 Web 客户端和手机上运行小程序。它也是一种后端语言，有许多框架可供选择。

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

• 客户端：Java Applet 与 Javascript
• 服务器：Java EE vs Javascript with Node.js + Express
• 手机：Java ME vs Javascript with Phonegap / Appcelerator
• 桌面：Java SE vs Javascript with Phonegap / Appcelerator

I hope the context is more clear now.

我希望上下文现在更清楚了。

采纳答案by J?rg W Mittag

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.

Java 和 JavaScript 都是编程语言。编程语言只是一堆抽象的数学规则。编程语言并不快。或者慢。他们只是有。

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 knowssomething about benchmarking, and even more importantly statistics. Also, the precisedefinition of what you actually meanby "fast" is pretty important, since it can also have significant influence on the benchmark.)

应用程序的性能与语言无关。最重要的因素是应用程序架构。然后是算法效率。然后是微优化。然后是编译器/解释器的质量。然后是CPU。也许中间还有其他几个步骤。然而，语言并没有直接发挥作用。（当然，如果你谈论的基准，那么也是特定基准起到了重要作用，以及如何很好地执行基准，它是如何运行的，谁执行基准家伙是否真的知道一些关于标杆，甚至更重要的统计数据。此外，您实际含义的精确定义“快速”非常重要，因为它也会对基准产生重大影响。）

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

然而，该语言可能会间接发挥作用：在 10 行高度表达、清晰、简洁、可读、分解良好、隔离的高级 Lisp 代码中，比在 100 行代码中更容易找到并修复性能瓶颈。纠结的低级 C。（请注意，这两种语言只是示例。我并不是要单独使用任何一种语言。）例如，Twitter 曾表示，如果使用一种表达能力不如 Ruby 的语言，他们就不会能够在如此短的时间内对其架构进行如此彻底的更改，以解决其可扩展性问题。Node.js 之所以能够提供如此出色的事件 I/O 性能，是因为 JavaScript 的标准库太烂了。（这样，Node.js 必须自己提供所有 I/O，因此他们可以从头开始针对事件 I/O 对其进行优化。Ruby 和 Python，例如，事件化的 I/O 库与 Node.js 的工作效果一样好，而且更加成熟……但是，Ruby 和 Python 已经拥有大型标准库，包括 I/O 库，所有这些库都是同步的，并且不需要不能很好地与事件库配合使用。JavaScript 不存在 I/O 库与事件 I/O 不兼容的问题，因为 JavaScript 没有 I/O 库一点。）

But if you reallywant 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.

但是，如果您真的想比较两者，这里有一个有趣的数据点供您参考：HotSpot 是一种更受欢迎、性能也更高的 JVM 实现，它是由一个团队创建的，其中包括：一个叫拉尔斯·巴克的人。但实际上，HotSpot 并不是凭空出现的，它基于 Anamorphic Smalltalk VM 的源代码，该 VM 是由一个团队创建的，其中包括一个名叫 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.

V8 是一种更流行、性能也更高的 JavaScript 实现，它是由一个团队创建的，其中包括一个名叫 Lars Bak 的人。但实际上，V8 并不是凭空出现的，它基于 Anamorphic Smalltalk VM 的源代码，该 VM 是由一个团队创建的，其中包括一个名叫 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. Thatis the onlydifference in performance. It's not about static vs. dynamic typing (Java isstatically 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.

鉴于两者或多或少相同，我们可以期待类似的性能。唯一的区别是 HotSpot 有一百多名工程师在它上面工作了 15 年，而 V8 有十几名工程师工作了不到 5 年。这是性能上的唯一区别。这不是静态类型与动态类型（Java是静态类型，但大多数 JVM 和 HotSpot 都没有进行任何静态优化，所有优化都是纯动态的）、编译与解释（HotSpot 实际上是用额外的 JIT 编译器解释的，而 V8纯粹编译），高级与低级。这纯粹是关于钱。

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 keepthe pair and just use a different benchmark. There's a reasonthe call the Computer Languages Benchmark Game a "game": they even encourageyou right on their own page to play around with the benchmarks to make any arbitrary language rise to the top.

但是我敢打赌，对于 Java 实现更快的每一对 Java 和 JavaScript 实现，我可以找到另一对 JavaScript 实现更快的对。此外，我可能可以保留这对并使用不同的基准。将计算机语言基准游戏称为“游戏”是有原因的：他们甚至鼓励您在他们自己的页面上玩基准测试，以使任何任意语言上升到顶部。

回答by Joshua

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.

在 Google Chrome 的 JavaScript JIT 出现之前，一旦问题变得足够大以克服加载时间，Java 就会胜过 JavaScript。

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.

由于整数与浮点数学，Java 仍应彻底击败 JavaScript。无论 JIT 有多好，它都无法真正弥补这一点。

WebAssembly will turn this on its head anyway.

无论如何，WebAssembly 都会改变它。

回答by Josh K

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.

它们只是名称相似，仅此而已。Java 被编译，而 JavaScript 被解释（大部分）。即使使用 V8 的即时编译器，Java 在任何方面都更快。

回答by Matt Briggs

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.

程序员喜欢比较执行速度，就像某种令人讨厌的内容一样。它只是一个指标，而且在大多数情况下，远非最重要的指标。Java 是一种混合语言，它对几乎任何事情都足够快，但又足够高，可以得到像 GC 这样的东西，而在类似的语言中通常不会得到这些东西。Javascript 是一种动态闭包语言，非常适合快速完成工作（也适用于陷入 OO 世界的 FP 程序员；-)）。在任何一个都合适的空间中没有多少交叉点。

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.

由于人们编写惯用 javascript（由函数组成的函数）的方式，它非常适合异步编程，可能比任何其他类似流行的语言都要好。Node.js 在处理大量短连接时表现出色，因此 javascript 非常适合这类事情。

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.

虽然 node.js 绝对是令人敬畏的，但成为新的热点并不意味着它在所有方面都是最好的，无论炒作是什么。如果一个 Java 应用程序可以被 node 替换，那么 Java 一开始就很可能并不合适。

回答by Stephen C

Here are some tests comparing Javascript (V8) and compiled Java:

以下是一些比较 Javascript (V8) 和编译的 Java 的测试：

• 32 bit
• 64 bit

• 32位
• 64位

They indicate that Java is generally faster¹. 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.

它们表明 Java 通常更快¹。但是，如果您仔细研究这些页面和链接的资源，您会发现很难将同类与同类进行比较。

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.

有趣的是，在“regex-dna”基准测试中，Javascript 明显优于 Java（在某些条件下）。我的猜测是，这是因为 Javascript regex 引擎比 Java regex 引擎快。考虑到正则表达式在典型 Javascript 应用程序中的重要性，这并不完全令人惊讶。

^{1 - Strictly speaking, you cannot say that language X is faster than language Y. You can only compare specificimplementations 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.}

^{1 - 严格来说，你不能说 X 语言比 Y 语言快。你只能比较各自语言的具体实现。我链接到的网站对此很清楚……如果您想通过首页进入。然而，从特定数据点进行概括并不是完全不合理的……而且显然不存在矛盾的数据点……在计算密集型任务中，Java 通常比 Javascript 快。但另一方面，这种表现往往不是客观重要的标准。}

回答by kls

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.

我只有一个轶事要补充：我最近在 Javascript (nodejs v0.6.8) 中重新实现了一个 Java calc 服务器（金融）。WRT 开发时间，与原始 Java 实现相比，Javascript 实现轻而易举，代码行数少得多。这是一股清新的空气，真的。

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.

基于 Javascript 的服务器能够以 2.4k 交易/秒的速度进行计算，而 Java 服务器使用更少的内存在相同的硬件上处理 400+/秒。我不会将速度提升归因于原始 V8 与 Java 7 的性能，而是归因于实现。Javascript 实现使用的数据结构少得多，方法调用少一个数量级，并采用更直接和简洁的方法。

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.

不用说，我对 node.js 的性能非常满意。而这个，来自一个只使用 Java 多年 (9) 年的人。

回答by Schalk Dormehl

http://benchmarksgame.alioth.debian.org/u64q/javascript.html

http://benchmarksgame.alioth.debian.org/u64q/javascript.html

(Remember to look at the cpu column as-well-as elapsed secs).

（记得查看 cpu 列以及经过的秒数）。

According to the above link JavaScript as reality stands now is much slower for almost everything.

根据上面的链接，现在的 JavaScript 几乎在所有方面都慢得多。