性能似乎并不是核心Python开发人员的主要关注点，他们似乎觉得“足够快”就足够好了，而且帮助程序员提高工作效率的功能比帮助计算机更快地运行代码的功能更重要。

然而，确实有一个谷歌项目unladen-swallow(现在已被放弃)，目的是生产一个与标准解释器兼容的更快的Python解释器。PyPy是另一个旨在生成更快Python的项目。还有Psyco，它是PyPy的前身，它可以在不更改整个解释器的情况下为许多Python脚本提供性能提升，还有Cython，它允许您使用非常类似于Python语法的东西为Python编写高性能C库。

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.

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

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

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

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

不同的优先级和动机。

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

由于JIT、曲轴、类型推断器和数据优化代码，V8的速度很快。标记指针，双精度对象的nan标记。 当然，它会在中间进行正常的编译器优化。

普通的ruby, python和perl引擎都不做这些，只是做了一些基本的优化。

唯一接近的主流虚拟机是luajit，它甚至不做类型推断、常量折叠、nan标记和整数，但使用类似的小代码和数据结构，不像糟糕的语言那么胖。 我的原型动态语言，potion和p2有和luajit相似的特性，并且性能优于v8。有了可选的类型系统，“渐变类型”，你可以很容易地超越v8，因为你可以绕过曲轴。看到飞镖。

已知的优化后端，如pypy或jruby仍然受到各种过度工程技术的影响。

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。

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

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