随着当今代码越来越复杂，代码需要设计成易于维护-也就是易于阅读和理解。
话虽如此，我不禁想起几年前运行的程序，比如Winamp或某些游戏，您需要一个高性能程序，因为您的486 100 Mhz无法使用那个美丽的mp3播放器播放mp3并消耗所有CPU周期。
现在我运行媒体播放器（或其他软件），开始播放mp3，它会占用我的四个核心中的其中一个的25-30％。这怎么可能！如果486都可以做到，同样的操作怎么会占用这么多处理器？
我自己也是一名开发人员，我曾经建议：保持代码简单，不要过早地进行性能优化。似乎我们已经从“尽可能少地使用CPU”变成了“如果不太占用CPU就可以”。
那么，您认为我们是否忽视优化而破坏了性能呢？
良好的代码不会影响性能，糟糕的代码才会影响性能。
我发现相反的情况更为真实。在我的经验中，最易读和易于维护的代码通常具有最佳总体性能。那些难以阅读且臃肿的代码往往存在性能瓶颈，并且这些瓶颈往往出现在极其难以移除或重构的地方，因此它们只会被留在那里。
如果你是winamp的粉丝，你可能会喜欢阅读这篇关于Justin Frankel在AOL收购WinAmp后的有趣经历的文章。
他最新的产品是Reaper。
优化在平台长期固定且你可以真正学习它时才有意义。这在游戏主机上仍然发生。
我曾为游戏编写过大量紧凑的汇编语言代码，我可以告诉你这需要时间。你一遍又一遍地编写相同的代码，并改变你的数据结构，试图获得更高的帧率。
PC应用程序上不再有这样的压力了。假设额外工作投入很少会产生回报，任何想要快速响应的人都会购买更快的电脑。
就 MP3 播放器而言，你可能在进行不同的比较。旧的 486 MP3 播放器只能播放 MP3 文件，媒体播放器带有大量花哨的效果、透明界面等等。更不用说它可能还在向全球各地的微软服务器汇报你在听什么歌曲了 :-)
实际上，我认为这个问题更普遍，我们现在期望的用户界面体验付出了 CPU 和内存的代价。我认为这将比代码结构的额外开销更重要（而且与10年前相比，我们的编译器也聪明了很多，所以我甚至怀疑在机器码级别上这是否是一个因素）。
开发人员不应该害怕优化他们的应用程序。今天应用程序的臃肿和缓慢令人震惊。
好看的代码可以是快速的代码。问题可能有很多：
我不会说快速代码已经死了。作为反例，看看操作系统代码（Linux中的O(1)调度程序就是一个例子），当然还有游戏代码。
很容易将过度设计的代码与清晰的代码混淆。前者通常难以维护，可能会产生难以理解的瓶颈。但是UML图表可能看起来非常整洁。
我不知道有任何一种好的编译器在给定干净、书写良好的源代码时不能生成快速高效的代码。
如果您使用某种形式的代码生成器，那么它将取决于生成器输出的源代码的“好坏”。过去，我曾看到过代码生成器为看似简单的操作创建了大量垃圾代码。我认为工具设计师们患上了“所有东西和厨房水槽”病。现代工具应该更加精简，但在支付大笔费用之前最好检查一下工具。
同样地，如果您编写自己的代码，今天我所知道的每个编译器都会接受良好、干净的代码并创建优化良好、快速的可执行文件（除非您为了调试等目的关闭了所有优化）。
祝福您，
-R
