Misleading question. V8 is a JIT (a just in time compiler) implementation of JavaScript and in its most popular non-browser implementation Node.js it is constructed around an event loop. CPython is not a JIT & not evented. But these exist in Python most commonly in the PyPy project - a CPython 2.7 (and soon to be 3.0+) compatible JIT. And there are loads of evented server libraries like Tornado for example. Real world tests exist between PyPy running Tornado vs Node.js and the performance differences are slight.

因为JavaScript实现不需要关心其绑定的向后兼容性。

Until recently the only users of the JavaScript implementations have been web browsers. Due to security requirements, only the web browser vendors had the privilege to extend the functionality by writing bindings to the runtimes. Thus there was no need keep the C API of the bindings backwards compatible, it was permissible to request the web browser developers update their source code as the JavaScript runtimes evolved; they were working together anyways. Even V8, which was a latecomer to the game, and also lead by a very very experienced developer, have changed the API as it became better.

OTOH Ruby(主要)用于服务器端。许多流行的ruby扩展被编写为C绑定(考虑RDBMS驱动程序)。换句话说，如果不保持兼容性，Ruby就永远不会成功。

今天，这种差异在某种程度上仍然存在。使用node.js的开发人员抱怨很难保持他们的本机扩展向后兼容，因为V8会随着时间改变API(这也是node.js被分叉的原因之一)。IIRC ruby在这方面仍然采取更为保守的方法。

There's a lot more impetus to highly optimize JavaScript interpretors which is why we see so many resources being put into them between Mozilla, Google, and Microsoft. JavaScript has to be downloaded, parsed, compiled, and run in real time while a (usually impatient) human being is waiting for it, it has to run WHILE a person is interacting with it, and it's doing this in an uncontrolled client-end environment that could be a computer, a phone, or a toaster. It HAS to be efficient in order to run under these conditions effectively.

Python和Ruby运行在一个由开发人员/部署人员控制的环境中。一个健壮的服务器或桌面系统，限制因素通常是内存或磁盘I/O，而不是执行时间。或者可以利用缓存等非引擎优化。对于这些语言，关注语言和库特性集而不是速度优化可能更有意义。

这样做的附带好处是，我们拥有两个出色的高性能开源JavaScript引擎，它们可以并且正在被重新用于各种应用程序，例如Node.js。

我相信这是因为不同的设计优先级和用例目标。

一般来说，脚本语言(又称动态语言)的主要目的是在本地函数调用之间充当“粘合剂”。这些原生功能应a)覆盖最关键/最常用的领域b)尽可能有效。

这里有一个例子: jQuery排序导致iOS Safari冻结 那里的冻结是由于过度使用get-by-selector调用造成的。如果get-by-selector可以在本地代码中实现，那么就不会有这样的问题了。

考虑一下V8演示中经常使用的光线跟踪演示。在Python世界中，它可以在本机代码中实现，因为Python为本机扩展提供了所有工具。但在V8领域(客户端沙盒)，除了让VM尽可能高效之外，你没有其他选择。所以唯一的选择是使用脚本代码来实现光线跟踪器。

不同的优先级和动机。

在Sciter中，我做了一个测试，在本地实现了几乎完整的jquery核心。在像ScIDE(由HTML/CSS/Script组成的IDE)这样的实际任务中，我相信这样的解决方案比任何VM优化都要好得多。

我刚刚遇到了这个问题，还有一个很大的技术原因导致了性能差异，但没有提到。Python有一个非常强大的软件扩展生态系统，但这些扩展大多数是用C或其他低级语言编写的，以提高性能，并与CPython API紧密相关。

有很多众所周知的技术(JIT、现代垃圾收集器等)可以用来加速CPython的实现，但所有这些技术都需要对API进行重大更改，破坏了过程中的大多数扩展。CPython会更快，但是Python吸引人的很多东西(广泛的软件堆栈)将会丢失。举个例子，有一些更快的Python实现，但与CPython相比，它们几乎没有吸引力。

正如其他人所提到的，Python有一个PyPy形式的高性能JIT编译器。

Making meaningful benchmarks is always subtle, but I happen to have a simple benchmark of K-means written in different languages - you can find it here. One of the constraints was that the various languages should all implement the same algorithm and should strive to be simple and idiomatic (as opposed to optimized for speed). I have written all the implementations, so I know I have not cheated, although I cannot claim for all languages that what I have written is idiomatic (I only have a passing knowledge of some of those).

我没有任何明确的结论，但PyPy是我得到的最快的实现之一，比Node好得多。相反，CPython位于排名最慢的一端。