Python很慢?不一定哦

请注意,这有点夸张。

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

但这很慢。

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

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

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

此处显示的工具:

  • pip是用于安装python库的工具
  • virtualenv是用于创建封闭环境的工具,因此您无需全局安装所有软件包
  • pytest是使用最广泛的测试库(也许标准库中的unittest使用得更多,但至少非常接近)

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

 
 
 
 
  1. > time pip --version
  2. 0.34 seconds
  3. > time virtualenv -p (which python3) venv
  4. 6.24 seconds
  5. > time pytest  # in an EMPTY directory
  6. 0.32 seconds
  7. > time pip install pytest  # already installed!!!
  8. 0.85 seconds

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

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

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

Imports(导入)

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

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

 
 
 
 
  1. try:
  2.     import numpy
  3.     NUMPY_AVAILABLE = True
  4. except ImportError:
  5.     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

当前标题:Python很慢?不一定哦
标题路径:http://www.shufengxianlan.com/qtweb/news15/334815.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联