最危险的性能瓶颈误解答案

【问题标题】：Most hazardous performance bottleneck misconceptions最危险的性能瓶颈误解
【发布时间】：2010-04-20 22:36:57
【问题描述】：

编写 Bespin（基于云、基于画布的代码编辑器 [以及更多]）的人最近谈到了他们如何重构和优化部分 Bespin 代码，因为他们误认为 JavaScript 很慢。事实证明，当一切都说完了，他们的优化并没有产生显着的改进。

我敢肯定，我们中的许多人都会根据类似于 Bespin 团队的误解编写“优化”代码。

开发人员通常会认同哪些常见的性能瓶颈误解？

【问题讨论】：

标签： performance language-agnostic optimization

【解决方案1】：

不分先后：

“Ready, Fire, Aim” - 认为你知道需要优化什么而不证明它（即猜测）然后采取行动，因为它没有帮助不大，因此假设代码必须是最佳的开始。

“Penny Wise, Pound Foolish” - 认为优化完全是关于编译器优化，在时间堆积如山的时候大惊小怪++i 与i++不必要地花在夸张的设计上，尤其是数据结构和数据库。

“Swat Flies With a Bazooka” - 非常迷恋在课堂上听到的最奇特的想法，以至于无论规模大小，它们都被用于一切。

“对性能的模糊思考” - 将“热点”、“瓶颈”、“分析器”和“度量”等术语抛诸脑后，就好像这些东西已经很好理解和/或相关。（我敢打赌，我会因此而受到打击！）好吧，一次一个：

热点 - 定义是什么？我有一个：它是一个物理地址区域，PC 寄存器大部分时间都在其中找到。这是 PC 采样器擅长寻找的东西。许多性能问题都表现出热点，但只有在最简单的程序中，问题与热点在同一个地方。
瓶颈 - 一个包罗万象的术语，用于表示性能问题，它意味着有限的通道限制了可以完成工作的速度。未说明的假设是这项工作是必要的。在我几十年的性能调优中，我实际上发现了一些这样的问题——很少。几乎所有的都具有非常不同的性质。与其走从 A 点到 B 点的最短路线，不如走一些小弯路，以函数调用的形式，只需要很少的代码，但不会花费很少的时间。然后这些弯路会进一步嵌套，有时有 30 层深。弯路嵌套得越多，它们中的一些越有可能是不必要的——实际上是浪费的——而且它几乎总是源于泛滥的普遍性——毫无疑问地过度沉迷于“抽象” .
profiler - 一个通用的好东西，对吧？您所要做的就是获得一个分析器并进行一些分析，对吗？当您的目标是找出需要解决的问题以获得更好的性能时，您是否曾想过欺骗分析器 告诉您很多事情是多么容易？在你的调用树的某个地方，塞进一点文件 I/O，或者对一些系统例程的一点调用，或者让你的邪恶双胞胎在你不知情的情况下做这件事。在某些时候，这将是您的问题，大多数分析人员会完全忽略它，因为他们考虑的唯一低效率是算法低效率。或者，并非所有例程都很小，而且它们可能不会在少数地方调用另一个例程，因此您的调用图表明这两个例程之间存在联系，但是 哪个调用？或者假设您可以计算出很大一部分时间花费在 A 调用 B 调用 C 的路径上。您可以查看它并认为您无能为力，如果您还可以查看正在传递的数据在这些电话中，您可以查看是否有必要。这是一个有趣的项目——选择你最喜欢的分析器，然后看看你可以用多少方法来欺骗它。也就是说，想办法让程序花费更长的时间而不让分析器知道你做了什么，因为如果你可以故意这样做，你也可以在无意中这样做。
measure -（即测量时间）这是分析器几十年来一直在做的事情，他们为自己测量的准确性和精度感到自豪。但是测量什么时间？为什么要准确？请记住，目标是精确定位性能问题，这样您就可以有效地优化它们以获得加速。当你得到那个加速时，它就是这样，不管你事先估计得有多精确。如果以牺牲定位精度为代价来获得测量精度，那么您只是买了苹果，而您需要的是橙子。

Here's a list of myths about performance.

【讨论】：

嗯，分析器对我来说非常有用，由于它们可测量和可感知，我已经做出了改进......我真的不明白你的意思。
@alex：是的，他们发现一些问题。你知道你没有更多的加速机会吗？没有证据不是没有证据。这是我的意思的一个例子，经过多次迭代，证明了超过 40 倍的加速：stackoverflow.com/questions/926266/…
+1，尽管我不同意（或误解）“瓶颈”部分。我的观点：瓶颈描述了限制的硬件组件 - 例如。 CPU、缓存、磁盘。当运行一个计算量很大的程序时，很少有所有组件都处于其极限——通常一个会成为瓶颈。您可以减少整体负载，您可以从一个组件中移除“压力”，使其不会那么早成为瓶颈，并且您可以在组件之间移动“压力”。
@peterchen：你是对的。我的不满是该术语通常适用于任何使软件花费比它应该更长的时间，并且作为一个隐喻，它具有误导性。这意味着赛马受到腿移动速度的限制（比如说）。可以肯定，但在非玩具软件中最典型的问题是，这匹马不是直线奔跑，而是沿着一条由嵌套弯路组成的分形海岸线，其中许多并不是真正必要的。我希望有一个更好的比喻来表达这个想法，因为人们并没有真正意识到这一点。
@peterchen：也许另一种说法是我们的调用树可能会长得太大，需要修剪。这有什么说法？或许是“葛根密码”？

【解决方案2】：

当一个人在没有有效配置文件的情况下进行优化时，就会发生这种情况。您在没有个人资料的情况下所做的一切都是猜测，并且可能会浪费时间和金钱。我可以列出一堆其他的误解，但很多都归结为这样一个事实，即如果有问题的代码不是顶级资源消费者，那么它可能就可以了。有点像展开执行磁盘 I/O 的 for 循环...

【讨论】：

绝对是最大的误解——你认为你知道它为什么慢。个人资料，个人资料，个人资料！
这里的关键字是有效。确保用于识别瓶颈的性能测试类似于生产负载。

【解决方案3】：

如果我将整个代码库转换为[在此处插入 xxx 最新技术]，它会快得多。

【讨论】：

PHB 比程序员自己更普遍地持有这种误解。猜猜谁做决定...

【解决方案4】：

关系数据库速度很慢。
我比优化器聪明。
应该对此进行优化。
Java 很慢

而且，不相关：

有些人在遇到问题时会想“我知道，我会使用正则表达式”。现在他们有两个问题。

-jwz

【讨论】：

见鬼，当我写我的答案时，这个答案还不在这里！哈哈。 :DDD
最有趣的是，我们的两个答案都得到了同样的支持：D。

【解决方案5】：

优化代码的错误部分（各位，使用您的分析器！）。
我的编译器中的优化器很聪明，所以我不需要帮助它。
Java 速度很快 (LOL)
关系数据库速度很快 (ROTFL LOL LMAO)

【讨论】：

您能帮我们展开 ROTFLLOLLMAO 吗？
叹息。我知道ROTFLMAO。中间的“LLOL”部分是什么？还是“LOLL”？ :-)
R.olling O.n T.he F.loor L.aughing L.aughing O.ut L.oud L.aughing M.y A.ss O.ff.我认为 ROTFLMAO 会更有意义。 :-)

【解决方案6】：

“这必须尽可能快。”

如果您没有性能问题，则无需担心优化性能（只需注意使用好的算法）。

这种误解还体现在尝试优化程序各个方面的性能。我最常看到这种情况，人们试图将低容量 Web 应用程序的执行时间缩短到最后一毫秒，却没有考虑到网络延迟将比他们的代码执行时间长几个数量级，从而减少了执行时间无论如何都无关紧要。

【讨论】：

【解决方案7】：

我的优化规则。

不要优化
现在不要优化。
配置文件以识别问题。
优化占用至少 80% 时间的组件。
找到一个速度提高 10 倍的优化。

我的最佳优化是将报告时间从 3 天缩短到 9 分钟。优化后的代码从三天缩短到三分钟。

在我的职业生涯中，我遇到了三个人，他们的任务是在 VAX 上生成比本地排序更快的排序。他们总是能够生产出只需要三倍时间的品种。

【讨论】：

【解决方案8】：

规则很简单：

尝试使用标准库函数首先。
尝试使用蛮力和无知。
在尝试进行任何优化之前证明您遇到了问题。

【讨论】：