何时考虑Java中的代码效率？

Question

现在，我正在学习不同的Java代码效率（big-O）。 我不禁想知道何时在现实世界的编程中考虑代码效率。

程序员在PDL / Pseudo阶段会想到什么？ 或者就像你在编写代码一样..

我很感激你对此的看法！

Answer 1

请注意，以下内容非常通用，因为这个问题非常重要。

在现实世界中，程序员倾向于在设计阶段考虑效率，通常在以下情况下：

• 他们解决的问题是时间紧迫的（例如：视频渲染和图像处理）
• 他们处理的数据量太大（例如：分析来自Feed的数十亿字符串）

否则他们大多使用“现成的”方法和设计原则。

在某些情况下，代码审查会从缺乏经验的开发人员那里获得糟糕的实现，而且还有相当多的返工和学习：）

有时一些现有的实现是性能密集型的，并且由于各种原因（知识匮乏，时间限制，'当时是一个好主意'，对问题的理解不清楚等等）。在这种情况下，通常会对实施进行事后检查，在这些情况下，还会考虑更好的实施和效率。

还要注意Knuth的名言：

我们应该忘记小的效率，大约97％的时间说：过早的优化是所有邪恶的根源。然而，我们不应该在关键的3％

中放弃我们的机会

和

在既定的工程学科中，容易获得的12％的改进从未被认为是边缘的，我相信在软件工程中应该有相同的观点

因此需要在时间投入，复杂性和优化方面取得平衡。有关详细信息，请阅读wiki link。

Answer 2

如果你能在PDL阶段看到非常大的n的复杂性将是O（2 ^ n）或甚至是O（n ^ 2）那么你会再想一想，但即便如此，你也可以将它们原型化只是为了看看会发生什么。

通常你首先得到正确的东西，因为你无法确定它的速度是多么快，然后你使用一个探查器（例如https://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html作为一个非常简单的例子）看看它在哪里实际上是在烧CPU，然后专注于那些位。

Answer 3

Big O表示法是表达算法效率的好方法，但在处理企业系统中的代码时，事情通常会变得更加复杂。从长远来看，整个系统的体系结构及其运行的基础设施可能会产生更大的影响（如果它们出错，可能会因performance and stability problems而更加昂贵。

Big O符号肯定是工程师在使用性能分析器和其他工具确定瓶颈时会考虑（或者说）的，并且正在寻找在瓶颈所在的领域实施更有效的算法。