代码清晰会扼杀应用程序性能吗？答案

【问题标题】：Is code clearness killing application performance?代码清晰会扼杀应用程序性能吗？
【发布时间】：2009-07-22 23:33:20
【问题描述】：

随着今天的代码越来越复杂，代码需要设计成可维护的——这意味着易于阅读和理解。

话虽如此，我还是忍不住想起了几年前运行的程序，例如 Winamp 或一些您需要高性能程序的游戏，因为您的 486 100 Mhz 无法播放如此漂亮的 mp3消耗所有 CPU 周期的 mp3 播放器。

现在我运行媒体播放器（或其他），开始播放 mp3，它占用了我四个核心之一的 25-30%。来吧！！如果 486 可以做到，播放要占用这么多处理器来做同样的事情吗？

我自己也是一名开发人员，我总是建议：保持代码简单，不要过早地优化性能。似乎我们已经从“试图让它使用尽可能少的 CPU”到“如果它不占用太多 CPU 就可以了”。

那么，您认为我们忽略优化会降低性能吗？

【问题讨论】：

我怀疑代码清晰是媒体播放器的问题。
虽然我认为这可能是一个值得回答的问题，但我觉得有点令人困惑的是，您对应用程序为何缓慢的第一个猜测是由于开发人员编写了清晰的代码。 :) 总的来说，尽管我认为很多人将一般的“软件膨胀”（一个相当模糊的术语）归因于某些现代应用程序的缓慢。
我不是说是原因，而是到处（包括stackoverflow）有人问，我应该使用这个还是那个来提高性能？答案几乎总是，“不，在出现问题之前不要关心性能”。因此，我们只将性能视为错误，而不是功能......
我认为很多 Stackoverflow 程序员都在做商业应用程序，你需要有可维护性。其他 Stackoverflow 程序员做网络，其中上市时间是关键。游戏程序员总是担心代码速度。首先你让它工作，然后你让它快速。
您是否尝试过在负载下运行相同的测试？也许“媒体播放器”注意到有更多可用 CPU 并试图提供最丰富的播放？

标签： performance optimization

【解决方案1】：

干净的代码不会影响性能。糟糕的代码会影响性能。

【讨论】：

说得好。干净的算法将胜过“调整过的”坏算法。对于 GUI 应用程序，一些开发人员不了解数据和事件驱动的用户界面是如何组装的，而“蛮力”替代方案会导致您所描述的内容。那不是代码清晰，而是代码天真。

【解决方案2】：

我发现事实恰恰相反。根据我的经验，阅读和维护最简单的代码往往是整体性能最高的。难以阅读的巨大泥球往往会在奇怪的地方出现性能瓶颈，几乎无法移除或重构，所以它们就被留在了那里。

【讨论】：

++ 我完全同意。stackoverflow.com/questions/926266/…
我更喜欢称它们为毛球，但 +1

【解决方案3】：

如果您是 winamp 的粉丝，您可能想阅读这篇精彩的文章，了解 AOL 收购 WinAmp 后 Justin Frankel 在 AOL 的有趣时光。

他的最新产品是Reaper。

当平台长期固定并且您真正可以学习时，优化最有意义。这仍然发生在主机游戏中。

我已经为游戏编写了很多紧凑的汇编语言，我可以告诉你这需要时间。你一遍又一遍地编写相同的代码并改变你的数据结构，试图获得一个很好的帧率。

PC 应用程序不再有这样的压力。假设付出的额外工作很少会得到回报，任何想要快速的人都会购买更快的计算机。

【讨论】：

【解决方案4】：

特别是关于 mp3 播放器，您可能不会比较喜欢与喜欢。您的旧 486 mp3 播放器除了播放 mp3 外几乎没有什么作用，Media Player 承载了一大堆做花哨的效果、航空界面和所有这些东西。更不用说它可能正在给家里和地球上的其他十几个地方打电话，让微软知道你也在列出什么:-)

实际上，我认为这是更普遍的说法，我们今天所期待的那种 UI 体验在 CPU 和内存方面都是有代价的。我认为这将比代码结构化带来的任何额外开销重要得多（而且我们的编译器也比 10 年前聪明得多，所以我什至怀疑这是机器代码级别的一个因素）

【讨论】：

我就是这么想的。 iTunes 使用可视化工具时使用的 CPU 是不使用可视化工具时的 9 到 10 倍。那就是使用过滤器（EQ 等）来增强在 486 天内可能没有被使用的声音。

【解决方案5】：

开发人员不应该害怕优化他们的应用程序。当今应用程序的臃肿和缓慢令人震惊。

【讨论】：

++ 不要重复是多余的重复，但你是对的。 stackoverflow.com/questions/926266/…
开发人员应该害怕优化。优化需要与其他需要做的事情一起优先考虑，比如更多/更好的功能、错误修复、可用性测试等。开发人员不应该是决定优化的人，除非他们也是产品所有者。
事后优化必须与其他所有事情一起优先考虑，但优化应始终作为开发人员开发的标准行动方案来实施。我们不应该故意编写非最优代码（没有压倒性的理由）。产品负责人不应该在开发细节上胡闹。

【解决方案6】：

好看的代码可以是快速的代码。问题可能有很多：

高级语言极大地缩短了开发时间，但会耗费处理器时间。对于大量应用程序，这是一个很好的权衡
程序员不像以前那样受过算法教育 - 这可能与高级语言有关，因为人们只是使用他们语言的内置 sort() 而不是选择快速排序而不是插入排序
应用程序现在做得更多。我很确定 Media Player 比旧版本的 WinAmp 具有更多功能

我不会说快速代码已死。对于反例，请查看操作系统代码（想到 Linux 中的 O(1) 调度程序），当然还有游戏代码。

【讨论】：

【解决方案7】：

就我个人而言，我总是力求在性能和可维护性之间取得平衡。我们已经远离了 CPU 时间昂贵而程序员便宜的时代，但作为用户和开发人员，发现相同的任务在更新、更快的相同软件的新版本上花费更长的时间是令人沮丧的硬件……所以，主观上，是的，我认为有些公司在另一个方向上走得太远了。

【讨论】：

我认为性能与可维护性相关，而不是与之相关。
在大多数情况下，是的，但我得到的（很差）更多的是你在自己的答案中指出的；我见过“超级可维护”的代码不仅速度慢，而且至少对我来说更难理解。正如我所说，“平衡”。为了滥用 80/20 规则，大多数应用程序不需要极致性能，但是，随着面向对象变得无处不在，应用程序（至少从用户的角度来看）变得更慢、更臃肿，而硬件速度不断提高。性能差异来自哪里？

【解决方案8】：

根据我使用非学术软件的经验，最大的性能杀手是使用许多抽象层，每层抽象都会造成适度的性能损失，但它们结合起来就像复利一样。每个都可能被认为是“好东西”和“推荐的做事方式”，直到您看到为它付出的代价。

您会在事件驱动设计中看到这一点，在这些设计中，设置属性等看似无辜的事情会在整个类网络中产生级联效应。

【讨论】：

【解决方案9】：

很容易将过度设计的代码与清晰的代码混淆。前者通常难以维护，并且会产生神秘的瓶颈。但是 UML 图可能看起来很整洁。

【讨论】：

【解决方案10】：

我知道目前没有任何案例表明，如果提供干净、编写良好的源代码，好的编译器不会生成快速、高效的代码。

现在，如果您使用某种形式的代码生成器，这将取决于生成器源输出的“优点”。当然，在过去，我已经看到代码生成器为看似简单的操作创建了大量的垃圾代码。我认为工具设计师患有“一切和厨房水槽”疾病。现代工具应该更精简，但在花大价钱之前检查工具是值得的。

同样，如果您编写自己的代码，我今天所知道的每个编译器都会采用优质、干净的代码并创建优化良好、快速的可执行文件。（除非您出于调试目的或类似目的关闭所有优化）。

干杯，

-R

【讨论】：

编译器很棒，但这并不意味着他们可以自己生成闪电般的代码。制作一个对媒体（音频 dsp、视频、动画）高效的应用程序仍然需要努力。很多工作。
我发现良好的性能来自于使用良好的数据结构、编写高效的算法、不做任何不必要的工作，并在使用分析器识别瓶颈后优化代码。我没有发现良好的性能与代码的干净程度有关。
一个蹩脚的算法会很慢，不管编译器多么“酷”并且代码可以完美维护。