最危险的性能瓶颈误解

Question

编写Bespin (基于云的基于画布的代码编辑器等)的人最近谈到了他们如何重新考虑和优化贝斯平代码的一部分，因为错误地认为JavaScript是慢的。事实证明，当所有的说和做，他们的优化没有产生重大的改进。

我相信，我们中的许多人都是基于与Bespin团队类似的误解来编写“优化”代码的。

开发人员通常使用哪些常见的性能瓶颈错误概念？

Answer 1

不按特定顺序：

“准备，火，瞄准”--认为您知道需要在不证明(即猜测)的情况下对哪些代码进行优化，然后对其进行操作，因为它没有多大帮助，因此假设代码必须是最优的。

"Penny Wise，and愚蠢“--认为优化是关于编译器优化的，是对++i和i++的吹毛求疵，而大量的时间被不必要地浪费在过度的设计上，特别是在数据结构和数据库上。

"Swat a Bazooka" --被教室里听到的最奇思妙想所吸引，所以不管规模大小，它们都能用于任何事情。

“对性能的模糊思考”-抛出像“热点”、“瓶颈”、“分析器”和“度量”这样的术语，好像这些东西是很好理解和/或相关的。(我敢打赌我会因此受到打击！)好的，一次一个：

• hotspot -定义是什么？我有一个:这是一个物理地址的区域，在那里，PC寄存器被发现了相当一小部分时间。这是一种PC采样器善于发现的东西。许多性能问题都存在热点问题，但只有在最简单的程序中，才会出现与hotspot is.
• bottleneck相同的问题--性能问题的所有术语，它意味着有限的通道限制工作的完成速度。未说明的假设是，这项工作是必要的。在我几十年的性能调优中，我实际上发现了一些类似的问题--非常少。几乎所有的人都有着截然不同的性质。不采取从A点到B点的最短路径，而是以函数调用的形式进行小绕道，这些函数调用需要很少的代码，但不需要花费很少的时间。然后，这些迂回采取进一步嵌套的迂回，有时30层深。迂回越多，它们中的一些就越有可能是不必要的--事实上，这是浪费--而且它几乎总是来自于奔腾的普遍性--对"abstraction".
• profiler的过度放纵--这是一件普遍的好事，对吗？你要做的就是找个侧写器做一些分析，对吧？你有没有想过，当你的目标是找出你需要修正什么才能获得更好的性能时，欺骗一个分析器告诉你很多事情是多么的容易吗？在您的调用树中的某个位置，设置一个小文件I/O，或者一个对某个系统例程的小调用，或者让您的邪恶双胞胎在您不知情的情况下这样做。在某种程度上，这将是您的问题，大多数分析器将完全错过它，因为他们考虑的唯一的低效率是算法的低效率。或者，并不是所有的例程都是小的，它们可能不会在少数地方调用另一个例程，所以您的调用图显示这两个例程之间有联系，但是哪个调用呢？或者假设你可以在A调用B调用C的路径上花费很大的时间，你可以看到它，你可以认为你没有什么可以做的，当你也可以查看那些调用中传递的数据时，你可以看到它是否必要。这里有一个有趣的项目-挑选你最喜欢的剖析器，然后看看你有多少种方式可以骗过它。也就是说，要想办法让程序花费更长的时间，而不需要分析器能够告诉你做了什么，因为如果你可以故意这样做，你也可以在没有意图的情况下完成它。
• 测量--即测量时间--这是分析人员几十年来所做的事情，他们对测量的准确性和准确性感到自豪。但是测量一下几点？为什么是精确的？记住，我们的目标是精确定位性能问题，这样您就可以对它们进行有效的优化以获得加速。当你得到加速，它是什么，它是什么，不管你事先估计得多么精确。如果这种测量精度是以牺牲位置精度为代价购买的，那么当你需要的是橘子时，你就刚刚买了苹果。--

Here's a list of myths about performance.

Answer 2

这就是当一个人在没有有效的配置文件的情况下进行优化时所发生的事情。你在没有个人资料的情况下所做的就是猜测，可能是在浪费时间和金钱。我可以列举一些其他的误解，但是很多人认为，如果所讨论的代码不是顶级的资源使用者，那么它可能是可以的。就像展开一个执行磁盘I/O的for循环.

Answer 3

optimizer.

• This

• 关系数据库是慢的。

• 我比更聪明，optimized.
• Java是慢的

而且，不相关的：

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

-jwz