vlambda博客
学习文章列表

未编译的Python代码比Go慢100倍,编译后呢?

作者丨 Rodrigo Ramirez
译者丨无明
策划丨小智
我是编译型编程语言的忠实粉丝,一直都是。虽然解释型编程语言可以让开发者更快地编写和测试代码,但我仍然认为编译器是值得长期投入的。

在我看来,编译型代码有两个明显的优势:

  • 每次修改代码都可以得到验证,甚至是在开始运行代码之前。

  • 更快的执行速度。根据具体情况,代码可能被编译成非常底层的运行指令。

我之所以要写这篇文章,是想比较一下编译型代码的执行速度会比解释型快多少。

因为我偏爱编译型编程语言,所以现在有个问题:我手头有很多感兴趣的代码,但它们都是用 Python 写的,我该怎么办?全部重写?部分重写?完全不重写?

先入之见  

在这篇文章里,我通过比较 Java、Go 和 Python 在处理不同任务时的性能表现来验证我对它们的一些先入之见。首先是 Python,我正在考虑要不要把它替换掉。至于 Java,我已经是 20 多年的粉丝了,一路看着它成熟,不管是性能还是功能都在变得更好。最后是 Go,我两年前才开始用它,但真的很喜欢它。虽然 Go 相比 Java 还缺失了一些特性,比如类继承,但它的语法简洁而紧凑,编译和执行速度都很快,生成的代码也很紧凑,还提供了优雅的 goroutine 来实现并发处理。

以下是我的一些先入之见。

  • 编译型代码的执行速度比解释型代码要快一个数量级。之前,我比较了使用 JIT 和不使用 JIT 编译 Java 代码所获得的性能,它们的比率大概是 30 比 1。

  • Go 的运行速度比 Java 要快一点。我记得在之前的工作中做过一些测试,发现 Go 在处理某些任务时要比 Java 快 30%,但最近一些文章又说 Java 比 Go 快。

先来测试一把  

我在之前的一篇文章中通过一些代码比较过 JIT 的性能,后来使用 Python 和 Go 也实现了一遍。这段代码计算 100 的 Fibonacci 数值,每一轮计算 50 次,并打印执行时间(纳秒),共计算 200 轮。代码可以在 https://github.com/rodrigoramirez/fibonacci 上找到。

三种语言的输出结果看起来像这样:

Java Go Python...122 123 11683119 107 11539123 104 11358120 115 11926119 118 11973120 104 11377109 103 12960127 122 15683112 106 11482...

平均值是这样:

Java Go Python130 105 10050

可以看到,在计算 Fibonacci 数值时,Java 比 Go 要慢一些,大概慢 24%,而 Python 几乎慢了 100 倍,也就是 9458%。

这个结果验证了我最初对 Java 和 Go 的判断,但让我感到吃惊的是 Python 的表现,它慢得不只是一个数量级,是两个!

我在想 Python 为什么会花这么多时间。

我首先想到的是,很多人关注的是 Python 的易用性,并通过牺牲性能来快速获得处理结果。我相信数据科学家们都是这么想的。况且有这么多现成的库可以用,为什么要去找其他的?迟早会有人优化它们的。

第二个原因是很多人没有比较过不同的实现,因为很多初创公司在激烈的竞争中忙于做出产品,根本无暇顾及什么优化不优化。

第三个原因,有一些方式可以让同样的 Python 代码跑得更快。

把 Python 代码编译一下会如何  

在做了一些调研之后,我决定使用 PyPy 测试一下相同的 Python 代码。PyPy 是 Python 的另一个实现,它本身就是使用 Python 开发的,包含了一个像 Java 那样的 JIT 编译器。跟 Java 一样,我们需要忽略初始的输出,并跳过 JIT 编译过程,得到的结果如下:

Java Go Python PyPy130 105 10050 1887

PyPy 的平均响应速度比 Python 快 5 倍,但仍然比 Go 慢 20 倍。

更多的测试  

以上的测试主要集中在数值的计算上,如果回到最开始所说的 Python 代码,我还需要关注:

  • Kafka、HTTP 监听器和数据库的 IO;

  • 解析 JSON 消息。

   总结     

本文通过执行简单的数学运算得出这样的结论:Go 的执行速度比 Java 快一些,比解释运行的 Python 快 2 个数量级。

基于这样的结果,我个人是不会使用 Go 来替换 Java 的。

另一方面,在高负载的关键任务上使用 Python 不是一个好的选择。如果你正面临这种情况,可以考虑使用 Python 编译器作为短期的应急方案。

在决定是否要重写 Python 代码时,还需要考虑到其他因素,比如 IO 和 CPU 方面的问题,但这些超出本文的范围了。

有人提醒我,使用 Go 和 Java 的 64 位整型只能准确计算出 92 的 Fibonacci 数值,再往后会出现溢出(译者:所以代码后来改成了计算 90 的 Fibonacci 数值)。但即使是这样,本文的结论仍然是有效的。

原文链接:

https://medium.com/swlh/compiled-vs-interpreted-code-performance-e1a63299760b