Python很慢？不一定哦

请注意，这有点夸张。

首先，我要说明我是专业从事python工作的，我做出了许多开源贡献，并且我所有的业余爱好项目都使用python进行。我喜欢python。

但这很慢。

这是Reddit等论坛上的常见主题，人们说您不能使用python，因为它运行缓慢。是的，我们都知道python很慢。但是我们也知道，通常会使事情变慢的不是语言，而是算法。

是的，与C语言相比，python语言的运行速度非常慢，但这并不是python速度慢的99%。 Python之所以缓慢，是因为许多(即使不是大多数)Python程序员不在乎或不了解他们所做工作对性能的总体影响。编写网络应用程序时基本上可以这样做，但是如果编写的库可供成千上万，十万甚至一百万的人使用，则可能会对性能产生重大影响。

让我们看一些Python运行缓慢的实际例子：

此处显示的工具：

pip是用于安装python库的工具

virtualenv是用于创建封闭环境的工具，因此您无需全局安装所有软件包

pytest是使用最广泛的测试库(也许标准库中的unittest使用得更多，但至少非常接近)

我之所以选择这些工具，是因为这是大多数人与python的首次互动，而这是我们专业人士每天与之互动的东西。

> time pip --version0.34 seconds> time virtualenv -p (which python3) venv6.24 seconds> time pytest # in an EMPTY directory0.32 seconds> time pip install pytest # already installed!!!0.85 seconds

这些测量是普遍的，因为它们是在新环境中且具有热缓存(我对具有冷磁盘缓存的virtualenv进行了15秒钟的测量)。 如果您的虚拟环境具有很多依赖性，那么pip安装(同样不做任何事情)的时间会增加。 很多。 我在另一个项目中测量了2.1秒。

在这里算法才是问题，不是python。 我的意思是，当我们解决算法问题时，语言将成为问题，而且它永远不可能比更快的语言快，但是我们几乎与任何地方都差不多。

我对此不够强调：python的基本工具链比它所需的要慢一个数量级。 有时更多。

Imports(导入)

在python中导入的惯用方式是个大问题。 在python中使用说说请求，您确实会在文件顶部导入请求，大多数人会认为这是免费的或接近免费的。 在python中，它并不是完全免费的，实际上，它要求导入urllib2，这是很慢的部分。 因此，人们认为请求的导入是免费的，而请求的作者则认为urllib2的导入是免费的。 到处都是这样：成千上万的人都认为进口是免费的。 他们不是。

我最常看到的一种模式是：

try: import numpy NUMPY_AVAILABLE = Trueexcept ImportError: NUMPY_AVAILABLE = False

并且在导入时运行。我们什么时候在库中使用该标志?通常从不，并且numpy导入非常昂贵。我的机器上200ms。因此，对于您的应用程序而言，它的启动性能非常出色，因为它的功能在启动路径中没有使用，在许多情况下根本没有使用。

开发时，这非常令人沮丧，因为您平均可以在整个工作日平均每分钟重新启动一次该过程。

我很高兴看到一年以前，因此pytz停止在导入时解析其整个时区数据库。从Django(可以说是最流行的Web框架)的启动开始，这节省了约100毫秒的时间。现在考虑一下，这种微小的变化将在10年内节省多少千瓦时。每次运行测试时，每次启动Web Worker时，都会在每个使用Django的站点上进行。这仅适用于Django!许多其他库和程序都使用pytz。

千纸之死

另一个问题是，人们认为“哦，启动时只有10毫秒，这没什么大不了的”，但是如果该启动每天进行数百万次，那将是真实数字。对于进口来说，这是正确的，但在更多事情上也是如此。后续问题是，人们已经引入了100种此类减速后，就会认为“仅再增加10毫秒”。因此，现在您只需要在1秒的基础上再加上10毫秒，即1%。没什么大不了的!因此，现在可以再增加10毫秒，这略低于1%。每次您使其变慢时，它就会变得更便宜(以百分比为单位)，以使其变得更慢。

请不要使用这种逻辑!

上面的pip安装示例是一个很好的案例研究。从磁盘加载字典并检查其是否包含字符串“ pytest”将比python的启动时间(约30毫秒)少。但这不是pip在做什么，它正在文件系统中运行，甚至正在加载python文件以获取其版本号(为什么?我没有询问它们!为什么它们仍然没有以有效的格式存储?)。

在pytest中，我们有一个类似的问题，性能回归已被引入了上千次，但是现在一切都很缓慢，并且没有明显的方法来摆脱这种情况。我已经提供了一些补丁，但是由于我在进行优化时进行了其他更改，因此我获得的大部分收益都被抹去了!

最后，我放弃了提交补丁程序，并构建了一个名为hammett的新测试运行程序，该测试运行程序与pytest兼容，但速度更快。我的意思是走得更快。我希望，如果有替代方案，人们可​以看到存在另一个可能运行缓慢的世界。

我们如何使python更快?

我们需要关心这一问题。

我们需要了解进口不是免费的。

我们需要研究整个生态系统的基本构建模块，或者解决基本程序和库中的性能问题，或者替换它们。

我们需要衡量。

一些开始的地方：

pytest：代替我使用hammett，或敦促pytest的向后兼容性大幅度中断，以提​​高性能

pip：至少缓存一些结果!我应该能够在执行每个命令之前运行“ pip install -r requirements.txt”，而不会注意到它

virtualenv：我还没有研究过，但是似乎可以写1218个文件，总计11.6MB，可以加快速度，或者避免做一些工作

编写基准：这可能是最简单的。例如，您可以将工具与其他语言的同类工具进行基准测试。我们至少应该知道我们是否比例如java慢一百倍。

更新：

事实证明，virtualenv家伙已经在此之上了!现在，版本20需要0.8秒才能完成与之前花费6.4相同的任务。为此，virtualenv团队值得高度赞扬!

原文网址：https://kodare.net/2020/05/19/python-is-slow-does-not-have-to-be.html

【责任编辑：赵宁宁 TEL：（010）68476606】