【问题标题】:How fast is Javascript compared to Java? [closed]Javascript 与 Java 相比有多快? [关闭]
【发布时间】:2011-04-13 00:13:35
【问题描述】:

是否有任何测试可以比较 Javascript 与 Java 的性能?

更新:既然每个人都在问为什么这个问题,这里有一些上下文:)

大家都知道——我希望——现在的 Javascript 不仅存在于 Web 客户端,还存在于带有 node.js 的 Web 服务器中。

它也可以通过 appcelerator 和 phonegap 在手机和桌面上运行。

它也可以在网络浏览器中大量使用,以使用户体验像桌面应用程序一样一流。

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

由于它们中的每一个都可以在上述区域中几乎/完全相互替代,因此我想知道它们之间的性能差异,对于我描述的每种情况:

  • 客户端:Java 小程序与 Javascript
  • 服务器:Java EE 与 Javascript 与 Node.js + Express
  • 手机:Java ME 与带有 Phonegap / Appcelerator 的 Javascript
  • 桌面:Java SE 与 Javascript 与 Phonegap / Appcelerator

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

【问题讨论】:

  • 这两种相互竞争的语言你在做什么?您是否希望在网络浏览器之外使用 JavaScript?
  • @John:参见 Node.js、V8、MongoDB....
  • 约翰是对的,没有上下文,这个问题没有多大意义。如今,Java 和 Javascript 在某些领域可以“竞争”,但它们仍然很少。为工作使用正确的工具!
  • 我想你是在问“嗨,你更喜欢哪个,果汁还是牛排?”
  • @John Kugelman。我是。阅读我打算在哪里使用它们,几乎在传统网络浏览器之外的所有地方。

标签: java javascript


【解决方案1】:

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

应用程序的性能与语言无关。最重要的因素是应用程序架构。然后是算法效率。然后是微优化。然后是编译器/解释器的质量。然后是CPU。可能还有其他几个步骤。然而,语言并不直接发挥作用。 (当然,如果您在谈论基准测试,那么特定的基准测试也会发挥作用,以及基准测试的实施情况如何,运行情况如何,执行基准测试的人是否真的知道 一些关于基准测试的东西,甚至更重要的是统计数据。此外,精确 对“快速”的实际意思 的定义非常重要,因为它也可以有对基准有重大影响。)

但是,该语言可能会间接发挥作用:在 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 库。)

但是,如果您真的想比较这两者,这里有一个有趣的数据点:HotSpot,它是目前更流行且性能更高的 JVM 实现之一,由一群人,其中包括一个名叫 Lars Bak 的人。但实际上,HotSpot 并不是凭空出现的,它是基于 Anamorphic Smalltalk VM 的源代码,由一个团队创建的,其中包括一个叫 Lars Bak 的人。

V8 是目前最流行且性能更高的 JavaScript 实现之一,它是由一个团队创建的,其中包括一个名叫 Lars Bak 的人。但实际上,V8 并不是凭空出现的,它基于 Anamorphic Smalltalk VM 的源代码,该 VM 由一个团队创建,其中包括一个名叫 Lars Bak 的人。

鉴于两者或多或少相同,我们可以预期类似的性能。唯一不同的是,HotSpot 有超过 100 名工程师工作了 15 年,而 V8 有十几名工程师工作了不到 5 年。 是性能上的唯一差异。这不是关于静态与动态类型(Java 静态类型,但大多数 JVM 和当然 HotSpot 没有进行任何静态优化,所有优化都是纯动态的),编译与解释(HotSpot 实际上是用一个额外的 JIT 编译器,而 V8 是纯粹编译的),高级与低级。纯粹是为了钱。

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

【讨论】:

  • 这就是为什么我问“Javascript 与 Java 相比有多快?”
  • >> Java 和 JavaScript 都是编程语言。 ... 编程语言并不快。或者慢。
  • 不同意。许多语言定义了当今 CPU 无法有效处理的功能。这就是为什么 java 通常会比 Smalltalk 执行得更快,而写得好的 C 通常会胜过 java。此外,如果一种语言是否具有自动内存管理功能,以及一种语言是否具有低级数据结构(byte[],C 中的结构)也很重要。
  • @R.Moeller - 许多语言特性确实使优化变得困难。然而,一个(假设的)“非常聪明”的编译器仍然能够将(比如说)Smalltalk 翻译成最佳的 Java,从而翻译成机器代码。 (如果人类可以做到,那么足够先进的编译器也可以做到。)“今天的 CPU”或“今天的编译器”不能做到这一点的事实从根本上说是当今技术的限制......而不是语言(s )。
  • @StephenC:实际上,HotSpot 一个 Smalltalk 虚拟机,因此,如果 Sun/Oracle 将所有资金投入到 Smalltalk 而不是 Java,那么 Smalltalk 将与今天是 Java。 (事实上​​,商业化的高性能 Smalltalks 并没有那么遥远。)请记住:当 Java 刚出现时,Smalltalks 比 Java 快。哎呀,当 Self VM(后来成为 Animorphic Smalltalk VM,成为 HotSpot 和 V8)第一次问世时,它与当时可用的许多 C++ 实现 竞争,并且比某些更快其中。
【解决方案2】:

我只有一个轶事要补充:我最近用 Javascript (nodejs v0.6.8) 重新实现了一个 Java 计算服务器(财务)。 WRT 开发时,与原始 Java 实现相比,Javascript 实现轻而易举,代码行数少得多。那是一口新鲜空气,真的。

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

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

【讨论】:

  • 我猜你现在比较的是同步和异步方法,而不是 Java 和 Javascript。 Node.js 是异步的,绝对胜过同步 tomcat servlet 和库。但这并不是因为 Javascript 更快,而是因为 async 比 sync 更好地利用资源。
  • 如果必须用 Java 编写另一个版本的程序,您期望在性能方面有什么变化?您认为从 JavaScript 版本中获得的见解会显着提高程序的性能(与第一个 Java 版本相比)吗?
  • 我在number-crunching 应用程序中比较了nodeJS 和纯C 的性能。 NodeJS 只比 C 慢 2.5 倍。
【解决方案3】:

这里有一些比较 Javascript (V8) 和编译后的 Java 的测试:

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

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

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

【讨论】:

  • >> 我的猜测是,这是因为 Javascript 正则表达式引擎更快... blog.chromium.org/2009/02/…
【解决方案4】:

显然是 Java。

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

我现在不再自夸了

编辑:解决帖子中的编辑问题

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

虽然 node.js 绝对令人惊叹,但成为新的热门并不意味着它在所有方面都是最好的,不管炒作说什么。如果 Java 应用程序可以被节点替换,那么 Java 可能一开始并不适合。

【讨论】:

    【解决方案5】:

    可能不会,但这并不重要。

    在 Google Chrome 的 JavaScript JIT 之前,只要问题大到足以克服加载时间,Java 就会战胜 JavaScript。

    由于整数与浮点数学,Java 仍应全面击败 JavaScript。再好的 JIT 也无法真正弥补这一点。

    WebAssembly 无论如何都会改变它。

    【讨论】:

    • Facebook 上的 PHP 问题已经够大了,然后他们编译了它。所以...
    • 您的最后一点不一定正确(也许是在 2010 年?)。 V8 将首先编译一个优化较少的函数,同时跟踪几次运行的类型等统计信息。假设您将数组中的所有数字相加。如果 V8 发现以前的值都是整数,它将重新编译函数以使用整数加法机器代码指令(它是“乐观的”)。如果在数组的中途突然出现一个字符串,它将翻转回优化程度较低的版本。因此,如果您保持一致,它可能会非常快。
    • 今年早些时候有一个很棒的 talk from Vyacheslav Egorov 对 V8 中的数组进行了深入的处理(除其他外)。
    • 啊,他们终于也解决了这个问题。我想随着时间的推移,这个答案会慢慢变得越来越不真实。
    【解决方案6】:

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

    (记得查看 cpu 列以及经过的秒数)。

    根据上面的链接,现在的 JavaScript 几乎所有东西都慢得多。

    【讨论】:

    • Java 几乎在所有情况下都使用 2-3 倍的内存...似乎不公平
    • 这个基准是不公平的。大多数java性能。是通过多线程获得的。您可以通过新进程和管道在 nodejs 中执行多线程。但这在这些测试中是缺失的。
    • @Stepan -- 这里是你如何贡献程序 -- benchmarksgame.alioth.debian.org/play.html#contribute
    【解决方案7】:

    它们只是名称相似,仅此而已。 Java 是在解释 JavaScript 时编译的(大部分情况下)。即使使用 V8 的即时编译器,Java 在任何方面都更快。

    【讨论】:

    • 公平地说,它们的相似之处远不止名称。对于初学者来说,由于使用了 C,它们在语法上都有相似之处。此外,Java 代码可以用 JavaScript 编写。最后,Java 附带了一个内置的 JavaScript 解释器,因此您可以将 JavaScript 嵌入到 Java 应用程序中。
    • 你有什么实际证据可以证明这种“速度更快”的疯狂说法吗?考虑到这两种语言经常在极其不同的领域中运行,我想说任何说“更快”的尝试都需要更多的上下文,因为我不认为 Java 只是更快(在所有方面)。你会使用 Java 小程序来做一些 JS 在睡觉时可以做的蹩脚的 DHTML 效果吗?小程序更快吗?
    • @Svend:您不会通过编写小程序或特定函数来对语言进行基准测试。做一些抽象数学、递归、用 10,000 个节点填充红/黑树、浮点计算、字符串操作等。我们不是在这里争论使用,我们争论的是哪个(核心)执行得更快。
    • 当你说的主要是关于 JS 的时候,你是因为像 GWT 这样的东西才这么说的吗? JS什么时候不解释?
    • @Esteban Araya:所有现代 JavaScript 执行引擎都有编译器。 V8 甚至是一个编译器,它甚至没有解释器。
    猜你喜欢
    • 1970-01-01
    • 2011-07-05
    • 2023-03-11
    • 2015-06-22
    • 2012-09-28
    • 2011-01-29
    • 2016-07-04
    • 2010-11-21
    • 1970-01-01
    相关资源
    最近更新 更多