再一次，我发现自己有一套broken assumptions。通过修改经过验证的最优算法来考虑虚拟内存，文章本身的性能提升了10倍：
在现代多发行CPU上运行 在某个千兆赫的时钟频率， 最坏情况下损失近1000万 每个VM页面错误的说明。如果你 正在运行一个旋转磁盘， 数字更像是1亿 指令。
O（log2（n））算法有什么用处 如果这些操作导致页面错误 和慢速磁盘操作？对于大多数 相关数据集一个O（n）甚至一个 O（n ^ 2）算法，避免页面 错误，将围绕它运行。
还有更多这样的算法吗？我们是否应该重新审视我们教育的所有基本组成部分？在编写自己的内容时还需要注意什么呢？
澄清：
所讨论的算法并不比经过验证的最佳算法快，因为Big-O符号存在缺陷或无意义。它更快，因为经过验证的最优算法依赖于现代硬件/操作系统中不正确的假设，即所有内存访问都是相同且可互换的。
答案 0 :(得分：14)
当您的客户抱怨您的计划进展缓慢或缺少关键截止日期时，您只需要重新检查您的算法。否则，请注重正确性，稳健性，可读性和易维护性。在实现这些项目之前，任何性能优化都是浪费开发时间。
页面错误和磁盘操作可能是特定于平台的。始终个人资料您的代码，以了解瓶颈所在。花时间在这些领域将产生最大的好处。
如果您对页面错误和磁盘操作速度感兴趣，可能需要注意：
同样，这些项目仅在达到质量，客户投诉和分析师分析了您的计划之后。
答案 1 :(得分：3)
重要的是要意识到big-O表示法的最常见用法（谈论运行时复杂性）只是故事的 half - 还有另外一半，即 space < / em>复杂性（也可以用big-O表示），这也很相关。
通常情况下，内存容量的增长超过了计算速度的提升（对于单核心 - 并行化可以解决这个问题），因此对空间复杂性的关注较少，但它仍然是应该牢记的一个因素，尤其是在内存有限或使用大量数据的机器上。
答案 2 :(得分：3)
我将扩展GregS的答案：区别在于有效复杂性和渐近复杂性。渐近复杂性忽略常数因子，仅对“足够大”的输入有效。通常情况下，“足够大”实际上可能意味着“比任何计算机都能处理的更大，现在和几十年”;这就是理论（合理地）获得不良声誉的地方。当然也有“足够大”意味着 n = 3！
的情况更复杂（也就是更准确）的方法是首先询问“您感兴趣的问题的大小范围是多少？”然后您需要测量该大小范围内各种算法的效率，感受'隐藏的常数'。或者你可以使用更精细的算法渐近法，它实际上可以估算常数。
要看的另一件事是“过渡点”。当然，在2
答案 3 :(得分：1)
我看到没有破碎的假设。 Big-O表示法是对非常非常简化的理想化计算机上的算法复杂度的度量，并忽略了常数项。显然，这并不是实际机器上实际速度的最终决定。
答案 4 :(得分：1)
O（n）只是故事的一部分 - 很大一部分，而且往往是主导部分，但并不总是占主导地位。完成性能优化（which should not be done too early in your development）后，您需要考虑所使用的所有资源。您可以概括Amdahl's Law表示您的执行时间将由最有限的资源控制。请注意，这也意味着还必须考虑您正在执行的特定硬件。对于大规模并行计算机（例如，CM或MassPar）高度优化且极其有效的程序可能在大矢量盒（例如，Cray-2）上或在高速微处理器上都不能很好地工作。该程序甚至可能在大量有能力的微处理器（map / reduce风格）上表现不佳。缓存，CPU通信，I / O，CPU速度，内存访问等不同平衡的不同优化意味着不同的性能。
当我花时间研究性能优化时，我们会努力在整个系统上实现“平衡”的性能。具有慢速I / O系统的超高速CPU很少有意义，等等。 O（）通常只考虑CPU复杂性。您可能能够权衡内存空间（展开循环不会使O（）感觉到，但它确实经常有助于实现性能）;关注缓存命中副线性内存布局副内存库命中; virtual vs真实记忆;磁带vs旋转磁盘vs RAID，依此类推。如果您的性能受CPU活动的支配，I / O和内存闲置，那么big-O是您最关心的问题。如果您的CPU为5％且网络为100％，那么您可以远离big-O并处理I / O，缓存等。
多线程，特别是多核，使得所有分析变得更加复杂。这开启了非常广泛的讨论。如果您有兴趣，Google可以为您提供数月或数年的参考资料。