我发现了一些例子，其中PyPy比Python慢。 但是:只在Windows上。

C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop

C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop

所以，如果你想到PyPy，忘了Windows吧。 在Linux上，你可以实现惊人的加速。 示例(列出1到1,000,000之间的所有质数):

from sympy import sieve
primes = list(sieve.primerange(1, 10**6))

这在PyPy上比在Python上快10(!)倍。 但不是在窗户上。那里的速度只有原来的3倍。

I did a small benchmark on this topic. While many of the other posters have made good points about compatibility, my experience has been that PyPy isn't that much faster for just moving around bits. For many uses of Python, it really only exists to translate bits between two or more services. For example, not many web applications are performing CPU intensive analysis of datasets. Instead, they take some bytes from a client, store them in some sort of database, and later return them to other clients. Sometimes the format of the data is changed.

BDFL和CPython开发人员是一群非常聪明的人，他们设法帮助CPython在这种情况下表现出色。这是一个无耻的博客:http://www.hydrogen18.com/blog/unpickling-buffers.html。我使用的是Stackless，它源自CPython，并保留了完整的C模块接口。在这种情况下，我没有发现使用PyPy的任何优势。

PyPy已经有Python 3支持一段时间了，但根据Anthony Shaw 2018年4月2日在HackerNoon发布的这篇文章，PyPy3仍然比PyPy (Python 2)慢几倍。

对于许多科学计算，特别是矩阵计算，numpy是更好的选择(参见常见问题:应该安装numpy还是numpypy?)

Pypy不支持gmpy2。您可以使用gmpy_cffi，不过我还没有测试它的速度，该项目在2014年发布了一个版本。

对于Project Euler问题，我经常使用PyPy，对于简单的数值计算，通常从__future__导入除法就足以满足我的目的，但截至2018年，Python 3支持仍在开发中，最好的选择是在64位Linux上。截至2018年12月的最新版本Windows PyPy3.5 v6.0处于测试阶段。

注意:与2013年提出这个问题时相比，现在的PyPy更成熟，支持也更好。避免从过时的信息中得出结论。

PyPy, as others have been quick to mention, has tenuous support for C extensions. It has support, but typically at slower-than-Python speeds and it's iffy at best. Hence a lot of modules simply require CPython. PyPy doesn't support numpy. Some extensions are still not supported (Pandas, SciPy, etc.), take a look at the list of supported packages before making the change. Note that many packages marked unsupported on the list are now supported. Python 3 support is experimental at the moment. has just reached stable! As of 20th June 2014, PyPy3 2.3.1 - Fulcrum is out! PyPy sometimes isn't actually faster for "scripts", which a lot of people use Python for. These are the short-running programs that do something simple and small. Because PyPy is a JIT compiler its main advantages come from long run times and simple types (such as numbers). PyPy's pre-JIT speeds can be bad compared to CPython. Inertia. Moving to PyPy often requires retooling, which for some people and organizations is simply too much work.

我想说，这些是影响我的主要原因。

第二个问题比较容易回答:如果所有代码都是纯Python，那么基本上可以使用PyPy作为替代。然而，许多广泛使用的库(包括一些标准库)是用C编写的，并编译为Python扩展。其中一些可以与PyPy一起工作，一些不能。PyPy提供了与Python相同的“面向”工具——也就是说，它是Python——但其内部结构不同，因此与这些内部结构交互的工具将无法工作。

至于第一个问题，我想这有点像第一个问题:PyPy一直在快速发展，以提高速度并增强与其他代码的互操作性。这使得它更像是实验性的，而不是官方的。

我认为，如果PyPy进入稳定状态，它可能会开始得到更广泛的应用。我还认为对Python来说，摆脱C语言的基础是一件很棒的事情。但这在一段时间内不会发生。PyPy还没有达到临界质量，它本身几乎足够有用，可以做你想做的所有事情，这将激励人们填补空白。

简单来说:PyPy提供了CPython所缺乏的速度，但牺牲了它的兼容性。然而，大多数人选择Python是因为它的灵活性和“包含电池的”特性(高兼容性)，而不是因为它的速度(尽管它仍然是首选)。