在这里，我将是一个反对的人，他说，学习优化，尤其是装配优化，更重要的是装配调试，永远不会太早。我相信，如果您是一名学生，您会从中获得最大的好处（因为这样您就不会有什么损失（即节省时间/金钱）），而且一切都会有所收获。
如果您从事该行业，但不擅长组装，那就不要。否则，如果您是学生或有时间，我会抽出时间学习反汇编程序，看看是否能找到比编译器更好的解决方案。如果我做不到，谁在乎！我刚刚学习了如何编写以及编译器，当您遇到发行代码中的错误（没有调试符号）并盯着反汇编时，这是一个巨大的好处，因为这是您唯一可以看的东西。
答案
这是我发现的关于优化的最佳资源之一。
http://www.agner.org/optimize/
在咆哮
如果您阅读了主要开发人员的一些文章（例如，进行EASTL的推理和对代码的仔细检查将导致您做出类似的评论，因为GCC很难插入此if语句，它将告诉您大多数人们告诉您，相信编译器并不总是正确的，尤其是在游戏开发中），然后涉足该行业，您会发现优化是日常工作，并且知道汇编输出意味着什么是一大优势。而且，人们似乎并没有意识到（尤其是在stackoverflow上）分析游戏非常困难并且并不总是准确的。
有一个警告。您可以花时间优化某些内容，然后再意识到那是浪费时间。但是你学到了什么？您学会了在类似情况下不要重复相同的错误。
在我看来，SO现在所采取的态度是该声明的一种宗教立场，除非您进行概要分析并且不要担心，否则编译器不会比您更了解。它阻碍了学习。我知道业内专家的薪水非常好（我的意思是非常好的钱），他们在组装过程中四处游玩以优化游戏和调试游戏，因为编译器不擅长或根本无法为您提供帮助，因为不能（与GPU相关的崩溃，无法在调试器中读取所涉及数据的崩溃等）。
如果某个喜欢这样做的人还没有完全意识到这一点，在这里提出问题，却被编译器比你更了解的许多答案而拒绝/关闭该怎么办！从来没有成为那些高薪程序员之一？
最后一个想法。如果您尽早开始这样做，您会发现很快您将开始编写性能最差的代码，因为编译器以相同的方式或以最佳方式对其进行了优化，因此性能没有任何改善，因为现在编译器可以对其进行优化。 。无论哪种情况，它都已成为习惯，并且您以这种方式编写代码的速度不会比以前慢。有两个示例（还有更多示例）：
- 除非您确实想要后增量，否则请先增量
- 使用恒定的局部大小变量而不是在循环内的容器上调用size（）来为容器编写循环。
编辑：在行业中又8年后更新。学习组装。了解优化器如何工作以及它们生成的程序集（CompilerExplorer是实现此目的的出色工具）。我在Test版本（用于内部测试的优化版本）中遇到了无数次崩溃，即使使用调试符号也无法依赖调试器。编译器已经优化了太多东西，而程序集是您从崩溃转储中查找错误的宝贵信息的唯一来源。如果幸运的话，每个构建都需要30到40分钟，并且在构建队列中排在首位-因此，您不能依靠某些传统技术来隔离错误。多人游戏会使情况变得更糟。了解程序集以及如何阅读优化的程序集将使您变得更好，最终对团队更有价值。