在2020年的dotPy大会因肺炎而被取消后，我们联系了两位原定参加大会的演讲者Victor Stinner和Julien Danjou以了解更多关于Python编程语言的性能问题。他们的演讲内容包括：如何最好地衡量Python的性能、速度慢的原因，以及正在实施的项目和具体的解决方案，这对大型应用程序的开发者来说可能是个问题。Stinner是Python指导委员会的成员之一，从2010年开始，他一直是核心开发人员，而Danjou则是监控服务Datadog的工程师，他一直在为Python程序开发profiler。
- 您是如何参与到Python及其性能方面的工作中来的？
Victor Stinner。作为CPython的核心开发人员，我已经在Python项目上工作了10年，在最近的一次选举中，我一直是Python指导委员会的成员。如今，我的工资是由Red Hat支付的，在Red Hat产品上维护Python的下游，比如Red Hat Enterprise Linux和Fedora，以及Python.org的上游。所以，我在努力保持Python与其他语言（如Rust或JavaScript）的竞争，并确保它的速度足够快，适合现有的和新的用例。Python的主要实现CPython的瓶颈之一就是不能够同时使用多个CPU。这在理论上已经可以实现，但实际上并不方便。我们需要找到一个更好的方法。
Julien Danjou。我做Python也有10年了。在Datadog，他们有一个想法，要为Python程序建立一个profiler来提高性能，所以我开始研究Python生态系统中存在的一切关于profiler的东西。我发现并没有一个完美的解决方案----基本上，所有已经构建的东西都只是做了一半的工作！于是我花了一年左右的时间来构建Python的分析器。所以我花了一年左右的时间来构建profiler，并提供给我们的客户。他们在他们的生产系统上运行，然后将性能数据传回我们的系统，我们再进行分析。在GitHub上，所有的东西都是开源的。
- 有什么最好的方法来分析Python代码的性能？
JD：如果你想分析你的代码，分析它在做什么，在哪里可以优化，在哪里可以花更少的钱，没有比分析CPU时间的profiling-profiling更好的方法了，而且还可以分析内存分配和I/O。而且为了高效，你必须直接在你的生产系统上进行剖析! 你的系统会经历很多不同的行为，这取决于每天的时间和运行的硬件和操作系统。因此，如果你不在生产系统上对软件进行配置，而是尝试在笔记本电脑上进行配置，你会得到错误的结果。还有一点很重要，那就是你必须以非常低的开销来做这个剖析，因为你不能让你的生产系统慢10倍。
- 为什么Python相对于其他语言来说会这么慢？
VS：我认为有一点很重要，那就是受Python性能影响的人是少数人。对于大多数人来说，Python的效率已经足够满足他们的用例了。此外，需要注意的是，CPython每年都在变快。现在，Python变慢的背后有不同的原因。第一种是官方的说法，即不存在这样的性能问题! 说这句话阻碍了我们对这个问题的研究。其他的原因主要是技术上的原因。Python是最古老的编程语言之一----30多年前的一些设计选择与当时的硬件有关，所以现在已经不存在了。例如，Python的第一个版本不支持线程，而我们知道，今天，所有的应用程序都在使用8到64个CPU的线程。而要改变Python的实现，使其更好地使用硬件，需要花费大量的精力，这主要是因为现在Python非常流行。所以我们每做一个小小的改动，每推一个不兼容的改动，都会有几十个人抱怨。但是为了能够适应新的硬件，我们必须要推不兼容的改动! 能够在语言的稳定性和实现的演进之间找到一个平衡点是一个非常困难的任务。
JD：我同意Victor的观点。我没有看到很多人在Python的上游工作，他们试图提高Python的性能，考虑到使用Python语言并希望从Python中获得更好的性能的人很多，这很可惜。
VS：我认为还有一个经济原因，阻止开发者花时间在优化上的原因，因为很难说得过去在性能上下功夫，因为大部分的钱通常都花在了开发上。但也有例外，有些公司会花钱给开发者做性能方面的工作，比如Dropbox在一个叫Pyston的项目上，Google用Unladen Swallow，微软在Pyjion上做的Pyjion。对于其他公司来说，有时解决方案更多的是找出代码中最慢的部分，然后用不同的语言重写这些部分，或者改变应用的架构，将流程拆成多个流程，或者更好地将工作负载分配到多个服务器上。Dropbox的例子很有意思，因为有两个开发人员在Pyston项目上工作了三年，用Pyston优化Python，而另一个团队则用Go语言重写了部分代码。在三年结束时，第二个团队成功地优化了Dropbox的工作量，于是公司停止了对优化的投入，因为客户不再需要它了。
JD：所以用Python编码的时候，你可能需要的硬件可能要大一点，只是因为它比直接做C语言要慢一点，但实际上你在开发时间和人员上的花费要少很多。有了Python，做任何事情的原型真的很容易! 做一个Python脚本，然后把它演化成一个真正的应用，真的很容易。而且它实际上比试图构建一个相当快速和低级的东西要便宜得多，要花很多钱在开发时间和复杂性上。所以这是一种权衡，但我认为这是值得的。
- 对于想要优化代码性能的Python开发者，您有什么建议？
JD：如果你想让你的Python程序变得更快，首先你需要做的事情其实就是配置文件。我确实说了很多，但是开发者需要了解自己的程序的瓶颈在哪里，是什么原因导致程序速度变慢，以及需要优化的地方。然后，作为开发者，在设计和构建应用的时候，你也需要提前想好了! 比如说，如果你要构建一个大型的应用，要进行分布式开发，那么你就需要考虑如何分担你的工作量。这也是你在其他编程语言中也会遇到的问题，但在Python中，全局锁有一些注意事项，这使得线程速度特别慢。所以你需要使用多进程，在不同的系统上分布，或者使用异步I/O，比如说，一个事件循环，基本上可以让你的程序变得更快，而不是像10年前或20年前那样只用线程。
VS：如果你关心性能，首先要做的事情就是运行一个基准测试。这是最重要的部分！你需要有一个参考点。你需要有一个参考点，以确保优化的速度真的更快。问题是很多开发者没有正确使用基准测试工具，最终做出了错误的决定。我个人花了很多时间来修复工具运行基准测试，因为我们在Python中没有非常可靠的基准测试工具，在两台电脑之间很难重现结果。我还创建了pyperf模块来帮助编写、运行和分析基准，现在的pyperformance基准套件就使用了这个模块。然后还有很多现有的解决方案可以提高性能--比如说科学部分，有Numba，这是一个JIT编译器，一般情况下，有PyPy的实现。但是要小心，根据你的工作负载，PyPy可能会使用更多的内存，这可能是个问题。而最后一个解决方案就是Julien已经说过的--改变你的工作负载的分布或架构。
- 曾经有人试图从CPython实现中移除全局解释器锁(GIL)以优化性能--目前这个项目的情况如何？
VS：当你增加更多的CPU、更多的线程时，应用程序的效率就会变得更低，这是反直觉的。而当我与Larry Hastings和其他从事Gilectomy项目的开发者讨论这个问题时，我的理解是，瓶颈之一是C API，因为我们暴露了太多的实现细节。
JD：我最后一次听说Gilectomy项目是在2年前。而且我觉得很多人其实都在等待Python能够运行成吨的线程。但我认为这很难，因为他们围绕着多线程在很多地方都是安全的评估来构建语言，你无法在不破坏很多Python代码的情况下改变这一点。所以这将是一件非常棘手的事情。
VS：还有一个实验性的项目，有子解释器，与多进程相比，它有一个不同的方法。它的想法是，在一个进程内，你有多个Python实例，每个实例都是独立的，有自己的内存和数据以及自己的GIL。通过使用这种设计，我们也许可以并行运行2个实例，比如说。但是实现这个项目需要花费大量的精力，现在没有多少人在做这个项目。领导者是Eric Snow，他在微软工作，但在空闲时间也在做这个项目。我也想帮忙，但我的时间不多，所以很遗憾，这个项目还没有准备好投入生产，但我有信心在某个时间点上会成功的！我也在努力帮助他。
而我听说的最后一个正在进行的优化Python的项目是HPy，这个项目包括为Python编写一个新的C API，不泄露任何实现细节。由于C API的原因，有些C扩展在PyPy上的速度比在CPython上要慢很多，因为PyPy不是用C语言写的。所以如果你想在PyPy上使用现有的C语言扩展，比如NumPy，它必须模拟对象在内存中的存储方式，效率真的很低。所以PyPy的开发者团队在这个项目上的研究表明，如果你把现有的C扩展转换为他们的新的C API，同样的C扩展在PyPy上的速度会变得快4倍左右，而在CPython上却不会变慢。值得注意的是，HPy项目是独立于CPython项目之外的，所以它不受CPython的向后兼容性和开发速度慢的限制。从长远来看，HPy团队希望得到CPython和Cython的支持，但也希望得到Rust和GraalPython的支持。
网友评论