Python 的低性能问题是无法忽视的

我看的是公众号上的 译文, 原文在 这里. 我觉得作者有个观点很正确,就是如果某个编程语言的流行度不断提高,那么它的低性能则是个不容忽视的问题,所有的使用者都在使用缓慢的版本,大量的资源被浪费。尤其可怕的是,如果社区把这种浪费当做是理所当然,或者是争辩说"相比机器开发效率更加重要",那么就是在刻意回避这个问题。

Python没有办法简单地利用多核,所以没有办法简单地享受到摩尔定律带来的免费午餐。而现实世界中需要处理的数据量越来愈大,计算模型越来越复杂,侧面就显得Python的性能越来越差。

首先,我工作的内容变了。以前我的很多工作可以轻松地写成numpy的操作(numpy使用编译好的代码,所以速度很快),现在我写的很多代码与数值没有关系。其次,如果我必须使用标准的Python写代码的话,那么代码会慢得像乌龟爬。我的意思不是说“等几秒”的慢,而是说“两分钟的事情慢到需要等几个小时。”

同时,数据量越来越大,而计算机的核心(可惜Python没法简单地利用多核)也越来越多,但单个核心的性能提升却非常缓慢。所以,从性能方面来说,Python是越来越差的选择。

其他语言在运行高级代码时(使用JIT或激进的编译时优化),也能展现良好的性能。从旁观者的角度看来,Python的核心开发团队似乎对性能问题并不感兴趣。他们开展了许多优化的项目,如psyco、 unladen swallow、 stackless、 shedskin、pypy等,但只有最后一个项目处于积极的开发中。但是,尽管他们忙来忙去,这些成果却从来没能应用到CPython,以致于CPython还在沿用20年前的字节码堆栈机的策略。虽说优化一个非常动态的语言必须谨慎行事,但是Javascript也和Python一样是动态的,已经有几个基于JIT的实现了。

程序员的时间比计算机的时间更有价值,这话虽然没错,但是等待计算结果也是浪费我的时间。虽然我觉得我可以在等待期间做点别的事情,但是切换思路让我很头疼,所以我宁愿等待。

作者还是比较客观的,不仅仅是考虑运行时间,也考虑开发时间和效率。

我主要的目的是为了节约总体花费时间,包括写代码的时间+运行代码的时间。

Python写代码的时间非常短,但是运行代码的时间却非常长。写代码的时间是人为因素(除了初学时的学习曲线外,我无法再有所提高)不计入内。但是一方面数据集越来越大,另一方面单个核心的性能又无法得到改善的情况下,运行代码的时间在不断增长,所以越来越值得花费更多时间优化代码,从而降低运行代码的时间。C++可以提供最短的运行代码时间,但是写代码的时间却太长(因为缺乏优秀的代码库和包管理)。所以至少对我来说Haskell是最好的选择。

上述方法适用于我的工作,因为我们使用大数据集作为输入,不过你的情况可能会有所不同。

如果某个软件被广泛使用的话,那么性能就不应该是个被忽略或者是回避的问题。

就目前的环境来说,Python也许是正确的选择,但并不是说不存在可以与Python媲美同时还能提供良好性能的语言。比如像Nim或F#这些语言已经很接近了。而且,当我知道Python也有高性能的衍生版本时,我认为它们应该成为主要标准,而且是唯一的标准。速度缓慢的版本不应该再存在。

我们的社区让速度慢的语言蓬勃发展是个巨大的错误,因为慢速工具流行意味着编程的速度也很慢,进一步浪费了他人的时间和精力。

另一个例子是Electron已成为了跨平台桌面应用的标准。为特定目的选择Electron固然没错,但软件社区允许这种毫无性能可言的东西发展成为最佳选择却是个错误。

不要再说“不喜欢慢的软件,你可以不用啊”,因为许多东西已成为事实上的标准,你无处躲避。公司可能要求使用Microsoft Teams作为交流工具,你就不得不仅仅为发几条消息而耗费大量的内存和电池。越来越多的人愿意为Atom开发语言插件,所以在选择优秀的IDE时,Atom就成了唯一可行的选择,于是你不得不忍受它的性能。