Knuth 说： 我们应该忘记小的效率，比如大约 97% 的时间：过早优化是万恶之源
我很好奇他是如何得出 97% 的。有人可以分享一下吗？
更新：问题是：这句话是写在研究论文中的，为什么主观陈述会在这样的正式文件中被接受？
【问题讨论】：
正如其他人指出的那样，只是一个粗略的数字。值得注意的是，从 70 年代（1974 年）开始，支持使用 goto 语句来加速软件中可测量的关键路径的引用。
当时应用程序的性质有点不同。硬件如此紧凑和有限，但没有说光线追踪产品的一半软件可能包括尝试追踪一千亿条光线并以速度为最终目标调用着色器。
如果我们想象像 Adobe Photoshop 这样的软件，可能至少有四分之一的软件会花费在循环像素上，而任何图像循环都对性能至关重要，因为它可以轻松循环数百万像素（只需取数我们的显示器显示为“基本”图形的像素）。因此，他们可能有四分之一或更多的代码库对关键路径进行建模，并真正受益于多线程、SIMD 或 GPU 处理等微观级别的优化。
真实数据会因上下文而大相径庭，但需要注意的一点是，Knuth 试图用该数据表达的是，一个不成熟的“优化器”很可能会尝试优化所有内容，无论是否这实际上很关键（以及它是否真的显示出真正的改进）。
【讨论】：
我相信 Mike Dunlavey 的回答是最接近的。我相信 Knuth 能侥幸逃脱只是因为他是“Knuth”。想象一下像我这样的人在一篇论文中说这句话。嗯……也许很多人会同意我的观点，但是在理论上证明之前，我的论文不会被接受。
人们分享了 Knuth 的感受，因为他们知道 Knuth 是谁。想象一下，他不知道 Knuth 是谁，我可以说他拒绝该陈述的概率会大大增加（斯蒂芬：不再是 97% ;)）
【讨论】：
这句话写在一篇研究中 论文，怎么来的主观陈述 在这样的正式文件中被接受？
因为研究不仅是事实，它也是公认权威的观点，无论是否有事实支持，也有直觉。请记住，爱因斯坦不相信海森堡测不准原理。
【讨论】：
我认为Knuth的说法主要是“声望论”的一个案例。谁来辩论？
我曾是一名教授，相信我，教授们可以逃脱许多松散的断言，尤其是在计算机科学领域。
我最喜欢的一个例子，教授们眼花缭乱的地方与软件性能有关，他们继续讨论大 O 和棘手的编译器优化，而完全忽略了由于大量过度设计而导致的巨大软件和大量低效率的工业现象.
【讨论】：
回答这部分问题：
这句话写在一篇研究中 论文，怎么来的主观陈述 在这样的正式文件中被接受？
如果研究满足相关学科中“研究”的规范，则该研究会被发表。比如：
实验物理和化学需要可重复的结果。如果结果不可重复，则对研究人员不利。
医学需要具有统计学意义的研究结果。大样本量的双盲研究是理想的，但此类研究通常过于昂贵，或者出于伦理原因而无法进行。
数学家需要证明。而且你最好不要滑倒。
哲学家喜欢一个很好的论据......我认为 nuf 谈到了他们。
除了数学之外，几乎所有研究论文都存在一定程度的主观性。但这并不一定会使它们变坏。主观陈述本身只有在读者容易将其误解为客观的情况下才会成为问题。
计算机科学和软件工程学科的论文特别容易出现一定程度的主观性。我认为这是不可避免的，因为在许多 CS/SE 领域中，进行能够让人们做出完全客观陈述的实验真的很困难（昂贵）。例如，您如何衡量过早的优化（而不是其他）是否导致了问题？或者更具体地说，如何客观地衡量单体内核是否优于微内核？
关于 Knuth 的引用（我假设）：
我们应该忘记小 效率，说大约 97% 时间：过早优化是 万恶之源。
这是主观的，但 Knuth 显然没有在此假装客观。相反，他以一种特别精练和令人难忘的方式给出了一些建议。正是这种东西让研究论文变得有趣，IMO。
郑重声明，97% 的经验丰富的软件开发人员都赞同 Knuth 的观点。 （我只是编造的:-)
【讨论】：
我不相信它应该按字面意思理解。在某些情况和环境中，优化是最重要的（因此是 97% 而不是说 99%），但是对于大多数程序员来说，编写大部分软件，大部分时间 - 优化应该只在必要时进行，并且经过适当的分析。
【讨论】：
80% 的统计数据都是当场制作的，包括这个。
我想你会发现Jon Skeet 的想法是对的。
【讨论】：
我认为这根本不是一个确切的数字。只是“几乎一直”。
【讨论】：