速度不再重要

　　过去的情形是，程序需要花费很长的时间来运行，CPU 比较贵，内存也很贵。程序的运行时间是一个很重要的指标。计算机非常的昂贵，计算机运行所需要的电也是相当贵的。对这些资源进行优化是因为一个永恒的商业法则：

　　优化你最贵的资源。

　　在过去，最贵的资源是计算机的运行时间。这就是导致计算机科学致力于研究不同算法的效率的原因。然而，这已经不再是正确的，因为现在硅芯片很便宜，确实很便宜。运行时间不再是你最贵的资源。公司最贵的资源现在是它的员工时间。或者换句话说，就是你。把事情做完比把它变快更加重要。实际上，这是相当的重要，我将把它再次放在这里，仿佛它是一个引文一样(给那些只是粗略浏览的人):

　　把事情做完比快速地做事更加重要。

　　你可能会说：“我的公司在意速度，我开发一个 web 应用程序，那么所有的响应时间必须少于 x 毫秒。”或者，“我们失去了客户，因为他们认为我们的 app 运行太慢了。”我并不是想说速度一点也不重要，我只是想说速度不再是最重要的东西;它不再是你最贵的资源。

　　速度是唯一重要的东西

　　当你在编程的背景下说 速度 时，你通常是说性能，也就是 CPU 周期。当你的 CEO 在编程的背景下说 速度 时，他指的是业务速度，最重要的指标是产品上市的时间。基本上，你的产品/web 程序是多么的快并不重要。它是用什么语言写的也不重要。甚至它需要花费多少钱也不重要。在一天结束时，让你的公司存活下来或者死去的唯一事物就是产品上市时间。我不只是说创业公司的想法 — 你开始赚钱需要花费多久，更多的是“从想法到客户手中”的时间期限。企业能够存活下来的唯一方法就是比你的竞争对手更快地创新。如果在你的产品上市之前，你的竞争对手已经提前上市了，那么你想出了多少好的主意也将不再重要。你必须第一个上市，或者至少能跟上。一但你放慢了脚步，你就输了。

　　企业能够存活下来的唯一方法就是比你的竞争对手更快地创新。

　　一个微服务的案例

　　像 Amazon、Google 和 Netflix 这样的公司明白快速前进的重要性。他们创建了一个业务系统，可以使用这个系统迅速地前进和快速的创新。微服务是针对他们的问题的解决方案。这篇文章不谈你是否应该使用微服务，但是至少要理解为什么 Amazon 和 Google 认为他们应该使用微服务。

　　微服务本来就很慢。微服务的主要概念是用网络调用来打破边界。这意味着你正在把使用的函数调用(几个 cpu 周期)转变为一个网络调用。没有什么比这更影响性能了。和 CPU 相比较，网络调用真的很慢。但是这些大公司仍然选择使用微服务。我所知道的架构里面没有比微服务还要慢的了。微服务最大的弊端就是它的性能，但是最大的长处就是上市的时间。通过在较小的项目和代码库上建立团队，一个公司能够以更快的速度进行迭代和创新。这恰恰表明了，非常大的公司也很在意上市时间，而不仅仅只是只有创业公司。

　　CPU 不是你的瓶颈

　　如果你在写一个网络应用程序，如 web 服务器，很有可能的情况会是，CPU 时间并不是你的程序的瓶颈。当你的 web 服务器处理一个请求时，可能会进行几次网络调用，例如到数据库，或者像 Redis 这样的缓存服务器。虽然这些服务本身可能比较快速，但是对它们的网络调用却很慢。这里有一篇很好的关于特定操作的速度差异的博客文章。在这篇文章里，作者把 CPU 周期时间缩放到更容易理解的人类时间。如果一个单独的 CPU 周期等同于 1 秒，那么一个从 California 到 New York 的网络调用将相当于 4 年。那就说明了网络调用是多少的慢。按一些粗略估计，我们可以假设在同一数据中心内的普通网络调用大约需要 3 毫秒。这相当于我们“人类比例” 3 个月。现在假设你的程序是高 CPU 密集型，这需要 100000 个 CPU 周期来对单一调用进行响应。这相当于刚刚超过 1 天。现在让我们假设你使用的是一种要慢 5 倍的语言，这将需要大约 5 天。很好，将那与我们 3 个月的网络调用时间相比，4 天的差异就显得并不是很重要了。如果有人为了一个包裹不得不至少等待 3 个月，我不认为额外的 4 天对他们来说真的很重要。

　　上面所说的终极意思是，尽管 Python 速度慢，但是这并不重要。语言的速度(或者 CPU 时间)几乎从来不是问题。实际上谷歌曾经就这一概念做过一个研究，并且他们就此发表过一篇论文。那篇论文论述了设计高吞吐量的系统。在结论里，他们说到：

　　在高吞吐量的环境中使用解释性语言似乎是矛盾的，但是我们已经发现 CPU 时间几乎不是限制因素;语言的表达性是指，大多数程序是源程序，同时它们的大多数时间花费在 I/O 读写和本机的运行时代码上。而且，解释性语言无论是在语言层面的轻松实验还是在允许我们在很多机器上探索分布计算的方法都是很有帮助的，

　　再次强调：

　　CPU 时间几乎不是限制因素。

　　如果 CPU 时间是一个问题怎么办?

　　你可能会说，“前面说的情况真是太好了，但是我们确实有过一些问题，这些问题中 CPU 成为了我们的瓶颈，并造成了我们的 web 应用的速度十分缓慢”，或者“在服务器上 X 语言比 Y 语言需要更少的硬件资源来运行。”这些都可能是对的。关于 web 服务器有这样的美妙的事情：你可以几乎无限地负载均衡它们。换句话说，可以在 web 服务器上投入更多的硬件。当然，Python 可能会比其他语言要求更好的硬件资源，比如 c 语言。只是把硬件投入在 CPU 问题上。相比于你的时间，硬件就显得非常的便宜了。如果你在一年内节省了两周的生产力时间，那将远远多于所增加的硬件开销的回报。

　　那么，Python 更快一些吗?

　　这一篇文章里面，我一直在谈论最重要的是开发时间。所以问题依然存在：当就开发时间而言，Python 要比其他语言更快吗?按常规惯例来看，我、google 还有其他几个人可以告诉你 Python 是多么的高效。它为你抽象出很多东西，帮助你关注那些你真正应该编写代码的地方，而不会被困在琐碎事情的杂草里，比如你是否应该使用一个向量或者一个数组。但你可能不喜欢只是听别人说的这些话，所以让我们来看一些更多的经验数据。

　　在大多数情况下，关于 python 是否是更高效语言的争论可以归结为脚本语言(或动态语言)与静态类型语言两者的争论。我认为人们普遍接受的是静态类型语言的生产力较低，但是，这有一篇优秀的论文解释了为什么不是这样。就 Python 而言，这里有一项研究，它调查了不同语言编写字符串处理的代码所需要花费的时间，供参考。

　　在上述研究中，Python 的效率比 Java 高出 2 倍。有一些其他研究也显示相似的东西。 Rosetta Code 对编程语言的差异进行了深入的研究。在论文中，他们把 python 与其他脚本语言/解释性语言相比较，得出结论：

　　Python 更简洁，即使与函数式语言相比较(平均要短 1.2 到 1.6 倍)

　　普遍的趋势似乎是 Python 中的代码行总是更少。代码行听起来可能像一个可怕的指标，但是包括上面已经提到的两项研究在内的多项研究表明，每种语言中每行代码所需要花费的时间大约是一样的。因此，限制代码行数就可以提高生产效率。甚至 codinghorror(一名 C# 程序员)本人写了一篇关于 Python 是如何更有效率的文章。

　　我认为说 Python 比其他的很多语言更加的有效率是公正的。这主要是由于 Python 有大量的自带以及第三方库。如果你不知道为何 Python 是如此的小巧和高效，我邀请你借此机会学习一点 python，自己多实践。这儿是你的第一个程序：

　　import __hello__

　　但是如果速度真的重要呢?

　　上述论点的语气可能会让人觉得优化与速度一点也不重要。但事实是，很多时候运行时性能真的很重要。一个例子是，你有一个 web 应用程序，其中有一个特定的端点需要用很长的时间来响应。你知道这个程序需要多快，并且知道程序需要改进多少。

　　在我们的例子中，发生了两件事：

　　我们注意到有一个端点执行缓慢。

　　我们承认它是缓慢，因为我们有一个可以衡量是否足够快的标准，而它没达到那个标准。

　　我们不必在应用程序中微调优化所有内容，只需要让其中每一个都“足够快”。如果一个端点花费了几秒钟来响应，你的用户可能会注意到，但是，他们并不会注意到你将响应时间由 35 毫秒降低到 25 毫秒。“足够好”就是你需要做到的所有事情。免责声明: 我应该说有一些应用程序，如实时投标程序，确实需要细微优化，每一毫秒都相当重要。但那只是例外，而不是规则。

　　为了明白如何对端点进行优化，你的第一步将是配置代码，并尝试找出瓶颈在哪。毕竟：

　　任何除了瓶颈之外的改进都是错觉。Any improvements made anywhere besides the bottleneck are an illusion. — Gene Kim

　　如果你的优化没有触及到瓶颈，你只是浪费你的时间，并没有解决实际问题。在你优化瓶颈之前，你不会得到任何重要的改进。如果你在不知道瓶颈是什么前就尝试优化，那么你最终只会在部分代码中玩耍。在测量和确定瓶颈之前优化代码被称为“过早优化”。人们常提及 Donald Knuth 说的话，但他声称这句话实际上是他从别人那里听来的：

　　过早优化是万恶之源Premature optimization is the root of all evil。

　　在谈到维护代码库时，来自 Donald Knuth 的更完整的引文是：

　　在 97% 的时间里，我们应该忘记微不足道的效率：过早的优化是万恶之源。然而在关 键的 3%，我们不应该错过优化的机会。 —— Donald Knuth

　　换句话说，他所说的是，在大多数时间你应该忘记对你的代码进行优化。它几乎总是足够好。在不是足够好的情况下，我们通常只需要触及 3% 的代码路径。比如因为你使用了 if 语句而不是函数，你的端点快了几纳秒，但这并不会使你赢得任何奖项。

　　过早的优化包括调用某些更快的函数，或者甚至使用特定的数据结构，因为它通常更快。计算机科学认为，如果一个方法或者算法与另一个具有相同的渐近增长(或称为 Big-O)，那么它们是等价的，即使在实践中要慢两倍。计算机是如此之快，算法随着数据/使用增加而造成的计算增长远远超过实际速度本身。换句话说，如果你有两个 O(log n) 的函数，但是一个要慢两倍，这实际上并不重要。随着数据规模的增大，它们都以同样的速度“慢下来”。这就是过早优化是万恶之源的原因;它浪费了我们的时间，几乎从来没有真正有助于我们的性能改进。

　　就 Big-O 而言，你可以认为对你的程序而言，所有的语言都是 O(n)，其中 n 是代码或者指令的行数。对于同样的指令，它们以同样的速率增长。对于渐进增长，一种语言的速度快慢并不重要，所有语言都是相同的。在这个逻辑下，你可以说，为你的应用程序选择一种语言仅仅是因为它的“快速”是过早优化的最终形式。你选择某些预期快速的东西，却没有测量，也不理解瓶颈将在哪里。

　　为您的应用选择语言只是因为它的“快速”，是过早优化的最终形式。

　　优化 Python

　　我最喜欢 Python 的一点是，它可以让你一次优化一点点代码。假设你有一个 Python 的方法，你发现它是你的瓶颈。你对它优化过几次，可能遵循这里和那里的一些指导，现在，你很肯定 Python 本身就是你的瓶颈。Python 有调用 C 代码的能力，这意味着，你可以用 C 重写这个方法来减少性能问题。你可以一次重写一个这样的方法。这个过程允许你用任何可以编译为 C 兼容汇编程序的语言，编写良好优化后的瓶颈方法。这让你能够在大多数时间使用 Python 编写，只在必要的时候都才用较低级的语言来写代码。

　　有一种叫做 Cython 的编程语言，它是 Python 的超集。它几乎是 Python 和 C 的合并，是一种渐进类型的语言。任何 Python 代码都是有效的 Cython 代码，Cython 代码可以编译成 C 代码。使用 Cython，你可以编写一个模块或者一个方法，并逐渐进步到越来越多的 C 类型和性能。你可以将 C 类型和 Python 的鸭子类型混在一起。使用 Cython，你可以获得混合后的完美组合，只在瓶颈处进行优化，同时在其他所有地方不失去 Python 的美丽。

　　星战前夜的一幅截图：这是用 Python 编写的 space MMO 游戏。

　　当您最终遇到 Python 的性能问题阻碍时，你不需要把你的整个代码库用另一种不同的语言来编写。你只需要用 Cython 重写几个函数，几乎就能得到你所需要的性能。这就是星战前夜采取的策略。这是一个大型多玩家的电脑游戏，在整个架构中使用 Python 和 Cython。它们通过优化 C/Cython 中的瓶颈来实现游戏级别的性能。如果这个策略对他们有用，那么它应该对任何人都有帮助。或者，还有其他方法来优化你的 Python。例如，PyPy 是一个 Python 的 JIT 实现，它通过使用 PyPy 替掉 CPython(这是 Python 的默认实现)，为长时间运行的应用程序提供重要的运行时改进(如 web 服务器)。

　　让我们回顾一下要点：

　　优化你最贵的资源。那就是你，而不是计算机。

　　选择一种语言/框架/架构来帮助你快速开发(比如 Python)。不要仅仅因为某些技术的快而选择它们。

　　当你遇到性能问题时，请找到瓶颈所在。

　　你的瓶颈很可能不是 CPU 或者 Python 本身。

　　如果 Python 成为你的瓶颈(你已经优化过你的算法)，那么可以转向热门的 Cython 或者 C。

　　尽情享受可以快速做完事情的乐趣。

　　作者：Nick Humrich — 坚持采用持续交付的方法，并为之写了很多工具。同是还是一名 Python 黑客与技术狂热者，目前是一名 DevOps 工程师。

　　End.

作者：Nick Humrich

来源：IT168

原文链接:Python 是慢，但我无所谓