这些天，我在学校学习不同的 Java 代码效率 (big-O)。 我不禁想知道何时在现实世界的编程中考虑代码效率。
这是程序员在 PDL/Pseudo 阶段考虑的事情吗？ 或者就像你在写代码一样..
感谢您对此的看法！
【问题讨论】：
标签： java algorithm performance functional-programming big-o
请注意，以下内容相当笼统，因为这个问题非常基础。
在现实世界中，程序员通常在以下情况下倾向于在设计阶段关注效率：
否则他们大多使用“现成的”方法和设计原则。
在某些情况下，代码审查会从缺乏经验的开发人员那里发现糟糕的实现，并且需要进行大量的返工和学习 :)
有时一些现有的实现是性能密集型的，并且由于各种原因（知识贫乏、时间限制、“当时这是个好主意”、对问题的理解不明确等）。在这种情况下，通常会对实施进行事后修复，在这些情况下，还会考虑更好的实施和效率。
还要注意 Knuth 的名言：
我们应该忘记小的效率，比如大约 97% 的时间：过早的优化是万恶之源。然而，我们不应该放弃那关键的 3% 的机会
和
在已建立的工程学科中，12% 的改进很容易获得，绝不会被认为是微不足道的，我相信同样的观点应该在软件工程中占主导地位
因此需要在时间投入、复杂性和优化之间取得平衡。如需更多信息，请阅读wiki link。
【讨论】：
如果您可以在 PDL 阶段看到对于非常大的 n，复杂性将是 O(2^n) 甚至 O(n^2)，那么您会再想一想，但即便如此，您也可以对这些进行原型化只是为了看看会发生什么。
通常你首先把事情做对，因为在它做对之前你无法真正判断它有多快，然后你使用分析器（例如https://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html，一个非常简单的例子）来查看它的实际位置烧掉cpu，然后专注于那些位。
【讨论】：
大 O 表示法是表达算法效率的好方法，但在企业系统中处理代码时，事情通常会变得更加复杂。从长远来看，由于performance and stability problems 的错误，整个系统的架构及其运行的基础架构可能会产生更大的影响（并且修复成本更高）。
当工程师使用性能分析器和其他工具确定瓶颈时，他们肯定会考虑（或根据）Big O 表示法，并希望在该瓶颈所在的区域实施更有效的算法。
【讨论】：