由于今天的代码变得越来越复杂，代码需要设计为可维护 - 意味着易于阅读和易于理解。
话虽这么说，我不禁记得几年前运行过的程序，比如Winamp或者你需要一个高性能程序的游戏，因为你的486 100 Mhz不会播放那些漂亮的mp3消耗所有CPU周期的mp3播放器。
现在我运行Media Player（或其他），开始播放mp3，它占据了我的四个核心之一的25-30％。来吧！！如果一个486可以做到这一点，那么回放如何占用这么多处理器呢？
我自己就是开发人员，我总是建议：保持代码简单，不要过早优化性能。似乎我们已经从“试图让它尽可能使用最少量的CPU”变为“如果它不需要太多CPU就可以”。
那么，您是否认为我们通过忽略优化来破坏性能？
答案 0 :(得分：35)
清洁代码不会扼杀性能。糟糕的代码会影响性能。
答案 1 :(得分：19)
我发现恰恰相反。根据我的经验，最简单的读取和维护代码往往是整体性能最高的。这是一个难以阅读的巨大的泥球，往往在奇怪的地方有性能瓶颈，几乎不可能移除或重构，所以他们只是离开那里。
答案 2 :(得分：5)
如果你是winamp的粉丝，你可能会想在AOL收购WinAmp后阅读这篇关于Justin Frankel在AOL的有趣时期的精彩文章。
他的最新产品是Reaper。
当平台长时间固定并且您可以真正学习它时，优化最有意义。这仍然发生在控制台游戏中。
为游戏编写了很多紧凑的汇编语言，我可以告诉你需要时间。你反复编写相同的代码并改变你的数据结构，试图获得很好的帧速率。
PC应用程序不再存在此类压力。假设所付出的额外工作很少会得到回报，任何想要快速的人都会买更快的电脑。
答案 3 :(得分：2)
特别是关于MP3播放器，你可能没有像喜欢那样比较。你的旧486 MP3播放器没什么，但播放MP3，媒体播放器携带一大堆cruft做花式效果，航空界面和所有这些东西。更不用说它可能会打电话回家和地球上的其他十几个地方让微软知道你列出的内容： - ）
实际上我认为这更为普遍，我们今天所期望的那种UI体验在cpu和内存方面都是有代价的。我认为这比代码结构的任何额外开销要大得多（而且我们的编译器比10年前更加聪明，所以我甚至怀疑它是机器代码级别的一个因素）
答案 4 :(得分：1)
开发人员不应该害怕优化他们的应用程序。今天的应用程序的臃肿和缓慢是令人震惊的。
答案 5 :(得分：1)
好看的代码可以是快速代码。问题可能很多：
我不会说快速代码已经死了。对于反例，请查看操作系统代码（Linux中的O（1）调度程序），当然还有游戏代码。
答案 6 :(得分：0)
就个人而言，我总是力求在性能和可维护性之间取得平衡。我们已经离开了CPU时间昂贵且程序员便宜的日子，但作为用户和开发人员，在新版本更快，更快速地运行相同软件的更新版本上找到相同任务需要更长时间，这是令人沮丧的硬件......所以，主观上，是的，我认为有些公司在另一个方向走得太远了。
答案 7 :(得分：0)
根据我对非学术软件的经验，最大的性能杀手是使用多层抽象，每一层抽象都会产生适度的性能损失，但它们结合了复合兴趣。每一个都可能被认为是“好事”和“推荐的做事方式”，直到你看到为它付出代价。
你会在事件驱动的设计中看到这一点，在这些设计中，设置属性等无辜的东西在整个类网络中都会产生级联效应。
答案 8 :(得分：0)
很容易将顶部设计的代码与清晰的代码混淆。前者通常难以维护，并且可能产生神秘的瓶颈。但是UML图可能看起来很整洁。
答案 9 :(得分：-1)
我知道目前没有一个好的编译器如果给出干净，编写良好的源代码就不能生成快速，高效的代码。
现在，如果您使用某种形式的代码生成器，它将取决于生成器的源输出的“良好性”。当然，在过去，我已经看到代码生成器为看似简单的操作创建了大量垃圾代码。我认为工具设计师患有“一切和厨房下沉”的疾病。现代工具应该更精简，但是在掏钱之前检查工具是值得的。
同样，如果您编写自己的代码，我今天所知的每个编译器都将采用良好，干净的代码并创建经过良好优化的快速可执行文件。 （除非为了调试目的而关闭所有优化或类似的东西）。
干杯，
-R