performance - 最危险的性能瓶颈误解

Question

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

我敢肯定，我们中的许多人都基于与 Bespin 团队类似的误解，不遗余力地编写“优化”代码。

开发人员普遍认同的一些常见的性能瓶颈误解是什么？

Answer 1

没有特定的顺序:

“准备，开火，瞄准” - 认为你知道什么需要优化而不证明它(即猜测)然后采取行动，因为它没有多大帮助，因此假设代码必须是最佳的。

“一分钱一分货，一磅愚蠢” - 认为优化全是编译器优化，大惊小怪++i对比 i++而大量时间被不必要地花费在过度设计上，尤其是数据结构和数据库。

“带火箭筒的特警苍蝇” - 如此迷恋在类里面听到的最奇特的想法，以至于无论规模大小，它们都可以用于一切。

《关于性能的模糊思考》 - 抛出诸如“热点”和“瓶颈”以及“分析器”和“测量”之类的术语，就好像这些东西很容易理解和/或相关。 (我敢打赌我会为此受到重创!)好吧，一次一个:

热点 - 定义是什么？我有一个:它是一个物理地址区域，在其中找到 PC 寄存器的时间很长。这是 PC 采样器擅长寻找的东西。许多性能问题都表现出热点，但只有在最简单的程序中，问题才会与热点在同一个地方。

瓶颈 - 一个用于性能问题的笼统术语，它意味着限制工作完成速度的有限 channel 。未说明的假设是这项工作是必要的。在我几十年的性能调优中，我实际上发现了一些类似的问题——很少。几乎所有的都具有非常不同的性质。与其走从 A 点到 B 点的最短路线，还不如走很少的弯路，以函数调用的形式，这需要很少的代码，但不是很短的时间。然后这些弯路走进一步嵌套的弯路，有时深 30 层。绕道嵌套得越多，其中一些绕道就越有可能是不必要的——实际上是浪费——而且它几乎总是源于飞驰的普遍性——毫无疑问地过度沉迷于“抽象”。

分析器 - 一个普遍的好东西，对吧？您所要做的就是使用分析器并进行一些分析，对吗？有没有想过当您的目标是找出需要修复的内容以获得更好的性能时，欺骗分析器让您什么都不告诉您是多么容易？在您的调用树中的某个地方，添加一些文件 I/O，或对某个系统例程的一些调用，或者让您的邪恶双胞胎在您不知情的情况下执行此操作。在某些时候，这将是您的问题，大多数分析人员会完全错过它，因为他们认为唯一的低效率是算法效率低下。或者，并非所有例程都很小，并且它们可能不会在少数地方调用另一个例程，因此您的调用图表示两个例程之间存在链接，但是哪个调用？或者假设您可以确定大部分时间花费在 A 调用 B 调用 C 的路径上。您可以查看它并认为您无能为力，如果您还可以查看正在传递的数据在这些电话中，您可以查看是否有必要。这是一个有趣的项目 - 选择你最喜欢的分析器，然后看看你有多少方法可以欺骗它。也就是说，想办法让程序运行更长时间，而探查器无法告诉您做了什么，因为如果您可以有意地这样做，那么您也可以在无意中这样做。

测量——(即测量时间)这就是分析人员几十年来所做的事情，他们以测量的准确性和精确度为荣。但是测量什么时间？为什么准确？请记住，目标是精确定位性能问题，以便您可以有效地优化它们以获得加速。当您获得这种加速时，它就是它的样子，无论您事先估计得多么精确。如果测量精度是以牺牲位置精度为代价的，那么当您需要的是橙子时，您只是购买了苹果。

Here's a list of myths about performance.