来源：网络

本文经授权转自公众号CSDN（ID：CSDNnews）

作者 | Serdar Yegulalp  翻译 | 苏宓

想让一个 Python 用户很生气？或许你只要说一句：“Python 很慢。”

在很多关键方面，的确如此。没有外部 C 语言编写的库的“纯”Python，在计算和处理对象时，远不如 C、C++、Java、Rust 或者 Go 那样快……

为了应对这个问题，Python 用户长期以来采用了绕过“纯 Python”的方式。想要更快的数学计算？用像 NumPy 或 Numba 这样的库，或者用 Cython 把代码编译成 C。这些外部解决方案确实有效，而且 Python 社区中有一整套文化专门研究如何高效使用它们。

但这些“捷径”总是有代价的。用 NumPy 时，你的代码需要变得更抽象，不像其他语言那样细节丰富。用 Numba（或者某些情况下是 Cython）时，你只能用 Python 语言的一个小子集来表达你要做的事，并且这种方式能达到的速度是有限的。

总的来说，大家一直在呼吁一个问题：我们能不能让 Python 本身更快，开箱即用？多年来，答案逐渐变得清晰：“也许可以，但这很难。”

1、为什么让 Python 变得更快这么难？

Python 的性能和它是解释型语言这件事没有太大关系。最大的问题在于，Python 本身的“灵活性”——也就是它的动态性。

像 C++ 或 Rust 这样的语言，如果你给某个东西命名，编译器就能根据这个名称推断出你是什么类型的数据。编译器可以利用这种一致性，生成高效的代码来处理它。

但在 Python 中，这种保证不存在。一个命名的对象可以是任何东西。每次你要用这个对象时，必须去查找它的类型，再决定能做什么。因此，很多常见的优化根本做不了。

2、为什么 Python 的类型提示救不了我们

Python 最近添加了类型提示功能，实际上在这里并不管用。它的目的是在代码运行前进行检查，而不是为了提高性能。其设计初衷就是让开发者提前检查代码的正确性，同时保持 Python 的灵活性。

那么为什么不创建一个使用类型提示来生成优化代码的 Python 方言呢？实际上，Cython 就有点类似。它能让代码更快，但只有在处理原生数据类型时，才能发挥较大作用。一旦你开始使用 Python 的对象类型（比如列表或字典），就得回到 CPython 运行时，性能就没那么好了。

不过，这个方法其实也不符合我们的初衷：我们不应该为了加速而离开 Python。所以问题就来了：能不能在 Python 内部搞定呢？

3、Python 现在如何加速？

最近几个版本的 CPython（Python 的官方实现）引入了一些优化提议——有些是短期内可以实现的，有些则是远期目标。这些提议是 Python 开发者打算从内部加速 Python 的初步尝试。

一种新的优化方式是专门化自适应解释器