Optimization 如何更好地进行优化？

提前道歉如果这个问题看起来有点宽泛或奇怪，我并不想冒犯任何人，但也许有人可以提出建议。我试着寻找类似的问题，但没有

哪些资源（书籍、博客等）可以更好地教授代码优化

关于使代码更具可读性，有很多参考资料（代码完整可能是首选）。但是，让它运行得更快、内存效率更高怎么样

当然有很多关于每种特定语言的书，但我想知道是否有一些书涉及内存/运算速度的问题，并且在某种程度上与语言无关

阅读。虽然这是“过早优化是万恶之源”这句话的来源，但当有人想把任何东西做得更快或更小的时候，不管他们在这个过程中有多么重要或是太晚，这句话就出现了，实际上是关于在你能做到的时候让事情变得高效的重要性

了解空间的复杂性和复杂性

举个例子，你想牺牲空间复杂度来换取时间复杂度，反之亦然

了解您选择的语言和框架提供的算法和数据结构的时间和空间复杂性，尤其是您最常用的算法和数据结构

阅读本网站关于创建好的哈希代码的问题的答案

研究采用的方法具有缓存的优点，而不存在不当使用过时数据的缺点。考虑应用于内存缓存中的简单性或困难性。考虑一下，当你说“拧紧它，我可以忍受它给我带来的加速。”考虑一下，当你说“拧它，我可以生活在缓慢的保证它给我新鲜”。 学习如何使用多线程。了解它何时提高性能。了解为什么它通常不起作用，甚至使事情变得更糟

看看他的许多作品，其中表现是他写作中经常关注的问题

了解如何将项目作为流或迭代进行处理，而不是每次都构建和重建充满每个项目的数据结构。了解什么时候你不这样做会更好

知道东西的价格。您无法合理地决定“我将在CPU缓存中工作，而不是在主存/主存中，而不是在磁盘/磁盘上，而不是通过网络”，除非您清楚地知道是什么实际导致了每一个被命中，以及成本差异是什么。更糟的是，如果你不知道它们的成本是什么，你就不能把它当作早熟的优化来解决——不费力去优化某些东西通常是最好的选择，但是如果你甚至不考虑它，你就不会“避免过早的优化”，你正在胡思乱想，希望它能起作用。 了解一下您使用的脚本引擎/抖动/编译器等为您做了哪些优化。学习如何与他们合作，而不是与他们对抗。学会不要重做不管怎样都会对你有好处的工作。在一两种情况下，您也可以将相同的一般原则应用到您的工作中

在本网站上搜索一些被视为实施细节的案例-是的，所有这些案例中，所讨论的细节在当时并不是最重要的，但所有这些实施细节的选择都是有原因的。了解他们是什么。学习反论点

编辑（我会继续添加一些）：

当然，不同的书在强调效率方面的观点不同，但是我记得Stroustrup的C++程序语言是一个好几次他会解释在几个与效率有关的不同选项之间的选择。以及如何不让为了效率而做出的决定“从外部”影响类的可用性

这让我想到另一点。关注在不同项目中重用的库代码的效率。你永远都不会想“也许我应该在这里手推一个新的来提高效率”，除非这是一个非常专业的案例，否则你要相信，在很多案例中，大量的工作都是为了使大量使用的类高效，并集中精力找出热点

至于专业案例，一些更模糊的数据结构对于它们所服务的案例来说是值得了解的。例如，DAWG是一种非常紧凑的结构，用于存储具有许多常见前缀和后缀（在大多数自然语言中，这是大多数单词）的字符串，您只想在列表中找到与模式匹配的字符串。如果您需要一个“有效载荷”，那么每个字母都有一个后续字母的节点列表的树（DAWG的泛化，但以该“有效载荷”而不是终端节点结尾）具有一些但并非所有的优点。他们还可以在

O（n）

time中找到结果，其中

n

是所搜索字符串的长度

多久会出现一次？不多。我曾经想到过一次（确实有几次，但它们都是同一个案例的变体），因此，在那之前，我不值得学习所有关于道格斯的知识。但我知道这是我以后需要研究的东西，它为我节省了千兆字节（实际上，对于一台16GB内存的机器来说，这实在是太多了，以至于不到1.5GB）。直接使用手动滚动的DAWG完全是过早的优化，而不是将字符串放入哈希集中，但是当它出现时，快速浏览意味着我可以

假设：“在DAWG中查找字符串是O（n）”“在哈希集中查找字符串是O（1）”，这两条语句都是正确的，但两者的速度往往是相当的。为什么？因为就字符串的长度而言，DAWG是O（n），就DAWG的大小而言，实际上是O（1）。就h的大小而言，哈希集是O（1）

CurrentMethod(param0.next, param1, param2, /*...*/);

param0 = param0.next;
goto startOfMethod;