在绝大多数情况下，算法的改进比优化的改进产生更大的差异。算法也比低级优化更便携。我的建议是遵循有关缓存重用的内存布局的一般最佳实践，避免过多的副本或通信，以理智的方式处理文件系统，并使浮点内核具有足够的向量化粒度。有时这足以达到可接受的高比例“峰值”（对于此操作）。

始终为您认为重要的操作（或通过分析发现重要的操作）绘制性能模型。然后，您可以使用性能模型来估计高度调整的实现可以提供什么。如果您认为加速是值得的（相对于您可以做的其他事情），那么进行优化。

也许最困难的挑战是设计高级的、重要的（从某种意义上说，很多代码将取决于这些选择）接口和数据结构，以便您可以在以后进行优化而无需更改 API。与具体的优化和一般准则相比，我不知道如何教这个，除非通过经验。使用对性能敏感的开源软件会有所帮助。与任何 API 决策一样，了解问题空间很重要。

您如何定义“优化”？从开发更好的算法或计算模型到使用手动调整的汇编程序，有一个完整的范围。

根据我的观点和经验，唾手可得的果实在中间的某个地方，例如选择最适合底层计算机体系结构的算法。算法不一定要新颖，您对底层架构的理解不一定要非常具体，例如

• 如果您知道您的架构支持 SIMD，请重新构建计算结构，以便您的操作可以用短向量来编写，
• 如果您知道您的架构是多核计算机，请尝试将您的计算任务分解为不相互干扰的单独子任务并并行运行它们（想想您的子任务的 DAG） ,
• 如果您的底层架构有 ​​GPU，请考虑将计算重新表述为一组线程以锁步方式遍历数据的方法，
• 等等...

所有上述特性，例如 SIMD、并行性和 GPU，无需太多底层知识即可访问，但只有在可以轻松利用它们的算法中才能真正提供优势。

我同意到目前为止已经提出的所有答案......我只想解决代码优化中另一个被忽视的方面：质量期望。

当用户试图解决越来越大的问题并且代码不足以满足用户的需求/期望时，通常会出现代码优化问题。应该在代码优化上投入多少时间取决于满足这一期望的需求。如果迫切需要竞争优势（例如，在其他人之前完成并发表您对热门话题的研究），那么投入大量时间当然是值得的。

当然，应该投入多少时间取决于您需要它的速度以及您希望代码的可移植性。通常，这两种需求相互冲突，您必须在开始优化之前决定哪个更重要。您想要的越便携，您就越需要依赖代码（算法/数据结构）的高级设计更改。您希望代码执行得越快，就必须使用特定于特定机器的低级优化（例如代码/编译器/运行时优化）对其进行调整。

您必须对花费这么多人工月（而且这些总是神话:-)）来获得执行速度进行（成本）分析。您必须弄清楚该软件将被使用多少次以及有多少人使用，以便您可以估算收益。

与往常一样，经验法则是著名的 80/20 法则。在某些时候，花费越来越多的时间来获得几个百分比（或更少）的运行时间并不会增加。但是你必须分析。

我真诚地同意上面的海报：确保你的 API 是经过深思熟虑的，所以它不需要很多更改，并确保代码是可移植和可维护的（考虑必须重新分析你编写的算法和细节十年前优化）。并确保您使用良好的编程实践和标准库。很有可能有人已经为您的应用程序考虑过最有效的算法。

引用 Donald Knuth 的话：“过早的优化是万恶之源”。所以分析你的代码，但不要太早。