在慢速机器上开发是否过早优化？

Question

  

我们应该在缓慢的盒子上发展，因为它迫使我们尽早优化。

兰德尔·海德（Randall Hyde）在The Fallacy of Premature Optimization中指出，围绕霍尔引用有很多误解：

  

我们应该忘记小的效率，大约97％的时间说：过早的优化是所有邪恶的根源。

特别是，尽管现在的机器与Hoare时代的机器相比尖叫，但这并不意味着“应该避免优化”。那么，当他建议我们应该在适度节奏的盒子上发展时，我尊敬的同事有一个观点吗？这个想法是，性能瓶颈对慢速盒子更具刺激性，因此它们可能会受到关注。

Answer 1

这应该是社区维基，因为它非常主观，并且没有“正确”的答案。

那就是说，你应该用最快的机器开发。是的，任何慢的东西都会引起刺激，并鼓励你解决减速问题，但只是付出很高的代价：

作为程序员，你的工作效率与你能掌握的事物的数量直接相关，任何减慢你的过程或阻碍你的事情都会延长你在短期内掌握这些想法的时间 - 记忆，让你更容易忘记它们，并且必须重新学习它们。

等待编译程序允许堆栈的错误，潜在问题和修复程序在您分散注意力时辍学。等待加载对话框，或者查询完成同样的中断。

即使你忽略了这种效果，你仍然可以得到后面陈述的真实性 - 早期的优化会让你在圈内追逐自己，破坏已经有效的代码，并猜测（通常精度不高）关于事物的位置可能会陷入困境。首先正确设计你的代码，你可以忘记优化，直到它有机会解决一下，此时任何必要的优化都是显而易见的。

Answer 2

慢速计算机无法帮助您找到性能问题。

如果您的测试数据只是表中的几百行，那么您的数据库将对其进行全部缓存，您将永远不会发现编写错误的查询或错误的表/索引设计。如果您的服务器应用程序不是多线程服务器，那么在用500个用户对其进行压力测试之前，您将无法找到它。或者，如果应用程序存在带宽瓶颈。

优化是“一件好事”但正如我对新开发人员说的那样，他们对如何做得更好有各种各样的想法'我不在乎你多快给我错误的答案'。先找到它，然后在找到瓶颈时加快速度。一位经验丰富的程序员将从头开始设计和构建它。

如果性能真的很关键（实时？毫秒事务？）那么你需要设计并实现一套基准和工具来科学地向你证明你的变化使它变得更快。有太多的变量会影响性能。

另外还有他们会带来的经典程序员借口 - '但它运行缓慢，因为我们故意选择慢速计算机，部署它时运行速度会快得多。'

如果你的同事认为重要的是给他一台慢速计算机并让他负责'表现'： - ）

Answer 3

我想这取决于你制作的内容以及目标读者的内容。

如果您正在为固定硬件（例如，控制台游戏）编写软件，那么请使用与您将部署的设备类似或相同的设备（至少是测试设备）。

如果您正在开发桌面应用程序或该领域的某些东西，那么可以在您想要的任何机器上进行开发，然后在之后进行调整以在所需的min-spec硬件上运行。同样，如果您正在开发内部软件，那么公司想要购买的机器可能会有最低规格。在这种情况下，在快速机器上开发（以减少开发时间，从而降低成本）并针对该最小规格进行测试。

最重要的是，您可以使用最快的机器进行开发，并测试您将支持的最小或最精确的硬件。

Answer 4

如果您正在接近最终测试和生产环境的硬件上进行编程，那么在发布代码时，您往往会发现不那么令人讨厌的意外。

我已经看到有足够的程序员被严重的，但由于他们的机器比他们的大多数用户更快地导致意外问题。但是，我也看到了数据出现同样的问题。代码在一个小数据集上进行测试，然后在一个大数据集上“崩溃”。

开发和部署环境中的任何差异都可能是意外问题的根源。

尽管如此，由于编程既昂贵又耗时，如果最终用户运行的是过时的设备，那么更好的解决方案是在测试时处理它（并在几个早期测试中安排检查可用性和时间）。

为什么只是因为担心错过潜在的问题而使你的程序员瘫痪？这不是一个理智的发展战略。

保罗。

Answer 5

对于Codd的爱，使用分析工具，而不是慢速开发机器！

Answer 6

应该避免优化，这不是给我们Vista吗？ ：P

但严肃地说，这总是需要权衡。要问自己的重要问题

您的最终用户将使用哪个平台？ 我可以放弃周期吗？如果我这样做会怎么样？

我同意大多数人的观点，即初始开发应该在最快或最有效（非必要）相同的机器上完成。但是对于运行测试，请在目标平台上运行，并经常进行测试。

Answer 7

我通常在最快的机器上开发我可以得到的。

大多数时候我正在运行调试版本，这已经足够慢了。

Answer 8

我认为这是一个合理的概念（但可能因为它对我有用）。

如果我的开发人员工作站速度过快，我发现我不会仅仅因为在重新生成软件映像或将其下载到目标时几乎没有时间损失。我说至少有一半的下载是不必要的，因为我只记得在我调试代码之前我错过了一些东西。

目标计算机很可能包含一个受限制的处理器。如果 - 在嵌入式MCU上 - 你每秒有一半的FLASH，RAM和时钟周期，开发人员在设计代码时会更加小心。我曾经为数据区域中的单个记录的长度（不是在RAM中但在串行eeprom中）建议了字节变量，并收到了“我们不需要吝啬”的回复。几个月后，他们达到了RAM上限（128KiB）。我的反思是，对于这个应用程序，永远不会有任何大于256字节的记录，因为没有RAM可以将它们复制到。

对于服务器应用程序，我认为有一个（很多）性能较低的硬件进行测试是一个好主意。两个或四个核心而不是十六个（或更多）。 1.6 GHz istdo 2.8。名单还在继续。服务器通常 - 由于每个人都与之交谈 - 这是系统架构的瓶颈。在您开始为它开发（服务器）应用程序之前很久。

Answer 9

取决于您的交货时间。如果您处于12个月的交付周期，那么您应该在速度合理的盒子上开发，因为从现在开始的12个月后，客户的“平均”盒子将比当前的“平均值”更好。

随着您的开发周期接近“今天”，您的开发机器应该接近客户盒子的当前“平均”速度。