我们应该如何处理优化问题中的过早优化讨论？答案

【问题标题】：How should we handle premature optimization discussion in optimization questions?我们应该如何处理优化问题中的过早优化讨论？
【发布时间】：2009-01-13 06:51:08
【问题描述】：

关于 SO 的几个问题会问：“其中哪个更快？”或“为什么这比替代方案更快？”有一个或多个答案来解释downsides of premature optimization，并建议用户分析他们的代码以首先识别瓶颈。

看到“过早的优化很糟糕！”，我（个人）很失望。答案在以下问题上获得投票：

一般来说是合理的。
有趣！性能比较读起来很有趣，即使它们并不经常有用。这是互联网。（猫的图片不是特别有用 ;-)

我们能否让第一个倾向于mention premature optimization 的人在他们的答案中引用单独的社区维基模式答案中的Is premature optimization really the root of all evil? 问题？

通过这样做，我们会稍微集中我们的信息 (DRY)，让人们可以根据他们认为适用的情况对过早的优化帖子进行投票。就个人而言，我更愿意阅读讨论的内容（通常很有趣），而不是一遍又一遍地看到相同的元讨论。

这是一个有点不同的故事，当 OP 显然不明白他们正在做的是试图优化时。在这种情况下，指出过早优化的弊端是一个合理的回应。但是当问题是“哪个更快？”这个问题是关于优化的，任何关于过早优化的讨论都不是一个合理的回答。

如果您有关于为什么这将是过早优化的具体信息，这也是不同的。然而，仅仅背诵 Knuth 的名言似乎很愚蠢、多余，而且不值得称赞。

也许其他用户的感觉和我不一样 - 我只是想我会把它扔在那里，因为我已经看到它发生了几次。

【问题讨论】：

Meta Stack 上的第一个问题！

标签： discussion support

【解决方案1】：

过早的讨论过早的优化讨论是万恶之源！

【讨论】：

+1 是一个有趣的大佬。
"过早的过早优化讨论讨论是万恶之源！"是万恶之源。

【解决方案2】：

请注意“哪个更快...？”之类的问题。不等同于实际优化的尝试。可能是这种情况，但请不要假设它是，除非 OP 说“我试图使这个链表实现更快，即使我只打算在列表中使用它少于 10 项”。

一位经验丰富的程序员曾开发过可扩展性良好的应用程序或库，他有一个良好的心智模型，知道哪些途径最有可能在必要时进行优化 - 就像我们大多数人知道给定的冷/热程度一样温度是，或者熟食柜台的那个人知道一堆冷盘有多重，然后才真正把它贴在秤上。因此，当需要测量性能和/或优化时，程序员可以通过避免不必要的工作来节省大量时间。

刚刚开始进行一般编程的人（例如，在了解一般算法权衡之前，例如 O(n²) 冒泡排序与 O(n log n) 快速排序），或者刚刚开始编程的人在特定的库或系统中，可能正试图发展对性能和优化技术的那种天生的理解或“智慧”。当然，可以花时间实际编写测试程序并自己测量，偶尔这样做也很好，但可以节省很多时间去询问已经了解相关情况的其他人。我们应该向他们指出有关性能指标的有用信息，而不仅仅是告诉他们他们正在做的是过早的优化。

我知道我一直站在围栏的两边（既是绩效建议的提供者也是接受者），当有人真正努力提供有用的帮助时，我总是感激不尽。

【讨论】：

【解决方案3】：

任何包含“过早优化”的帖子还应该包含一个具体的、准确的答案，以证明这种优化是合理的。

我厌倦了人们一次又一次地谈论过早优化。我知道这是一个重要的教训，但是这里有太多的问题被忽略，这最终并没有多大帮助。

【讨论】：

【解决方案4】：

如果您认为这些答案没有帮助，请投反对票。如果他们所做的只是说过早的优化是一件坏事，那么他们并没有真正回答“哪个更快，为什么？”的问题。

说“过早的优化是一件坏事，但这是最快的方法”的答案很有帮助，所以我会投票赞成（如果原因是虚假的，则反对）。

SO 正在按预期工作。

【讨论】：

同意，似乎很多用户都以“过早的优化是一件坏事”开始他们的回答，所以我们从来没有真正衡量过它的适用性。

【解决方案5】：

前几天有一个问题，关于比较两个数字并获得最高数字的方法是最快的。这句话在这里非常正确，如果您要尝试优化此类事情，那么您要么正在处理一个非常小的应用程序，要么您的优化问题存在于其他地方。

如果您有两个解决方案，并且想知道哪个更快，只需组合一个小测试用例，实际测量哪个更快。正常的答案是没关系，让我们继续前进。过早的优化是不好的，因为您最需要做的优化是测量实际导致应用程序变慢的原因，并将精力集中在真正的减速上，这通常发生在您意想不到的领域。是的，总有程序员说他们能感觉到什么是需要时间的，也有很多同样的人在发现瓶颈完全是别的东西时感到惊讶。

比较可能是木匠开始随机切割而不是先测量。

【讨论】：

【解决方案6】：

当它没有根据时，我也会觉得它很烦人。这是一个简单的答案，只是引用过早的优化来回答一个一般问题，甚至不建议作者甚至试图优化任何特别的东西。

但是 - 有时这是有道理的，明智的“钓鱼竿”答案是建议进行分析，而不是沉迷于甚至可能不存在的成本。

有时这个问题确实带有过早优化的味道，例如：

“嗨，我有这段代码我已经写了，根本没有分析它（'什么是探查器？'），我想知道如果我重命名它是否会更快我的变量名称要更短，以便计算机可以理解他们更快。”

...那时唯一体面的答案就是成为鹦鹉，谈论分析的重要性，更好地适应要优化的内容（更重要的是，不优化的内容），以及主要进行微优化事后看来。

对于更多的理论/一般性问题，询问什么可以更有效，这不是一个非常合适的回答，甚至认为作者实际上在这种情况下过早地进行了优化是相当粗鲁的。但是问题中存在一些明显的过早优化气味（如上面夸张的问题），这成为唯一合理的答案。

【讨论】：