在慢速机器上开发是否是过早的优化？
我们应该在慢速 boxen 上进行开发，因为它迫使我们尽早优化。
Randall Hyde 在过早优化的谬误中指出，围绕霍尔的名言：
我们应该忘记小效率，大约 97% 的情况下：过早的优化是万恶之源。
特别是，尽管现在的机器与霍尔时代的机器相比已经很出色，但这并不意味着“应该避免优化”。那么，我尊敬的同事建议我们应该以适度的节奏进行开发，这有道理吗？这个想法是，性能瓶颈在速度慢的机器上更令人恼火，因此它们可能会受到关注。
We should develop on slow boxen because it forces us to optimize early.
Randall Hyde points out in The Fallacy of Premature Optimization, there are plenty of misconceptions around the Hoare quote:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
In particular, even though machines these days scream compared with those in Hoare's day, it doesn't mean "optimization should be avoided." So does my respected colleague have a point when he suggests that we should develop on boxes of modest tempo? The idea is that performance bottlenecks are more irritating on a slow box and so they are likely to receive attention.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
这应该是社区维基，因为它非常主观，并且没有“正确”的答案。
也就是说，您应该在可用的最快的机器上进行开发。是的，任何较慢的事情都会带来刺激并鼓励您解决速度缓慢的问题，但代价非常高：
作为程序员，您的生产力与您头脑中可以容纳的事物的数量以及任何会减慢进程的事物直接相关或阻碍你，会延长你在短期记忆中保留这些想法的时间，使你更有可能忘记它们，并且不得不重新学习它们。
等待程序编译会让你分心时一堆错误、潜在问题和修复程序会从你的脑海中消失。等待对话框加载或查询完成也会类似地中断您。
即使你忽略了这种影响，你仍然得到了后面的陈述的真相 - 早期的优化会让你在原地打转，破坏已经可以工作的代码，并猜测（通常准确度很低）事情可能会陷入困境。向下。首先正确地设计你的代码，你可以忘记优化，直到它有机会安定下来，此时任何必要的优化都会显而易见。
This should be community wiki since it's pretty subjective and there's no "right" answer.
That said, you should develop on the fastest machine available to you. Yes, anything slower will introduce irritation and encourage you to fix the slowdowns, but only at a very high price:
Your productivity as a programmer is directly related to the number of things you can hold in your head, and anything which slows down your process or impedes you at all lengthens the amount of time you have to hold those ideas in short term-memory, making you more likely to forget them, and have to go re-learn them.
Waiting for a program to compile allows the stack of bugs, potential issues, and fixes to drop out of your head as you get distracted. Waiting for a dialog to load, or a query to finish interrupts you similarly.
Even if you ignore that effect, you've still got the truth of the later statement - early optimization will leave you chasing yourself round in circles, breaking code that already works, and guessing (with often poor accuracy) about where things might get bogged down. Design your code properly in the first place, and you can forget about optimization until it's had a chance to settle for a bit, at which point any necessary optimization will be obvious.
速度慢的计算机不会帮助您发现性能问题。
如果您的测试数据在表中只有几百行，您的数据库将全部缓存，并且您永远不会发现编写错误的查询或错误的表/索引设计。如果您的服务器应用程序不是多线程服务器，您将无法发现这一点，直到您对 500 个用户进行压力测试。或者应用程序是否出现带宽瓶颈。
优化是“一件好事”，但正如我对那些对如何做得更好有各种想法的新开发人员所说的那样，“我不在乎你多快给我错误答案”。首先把事情做好，然后在发现瓶颈时加快速度。经验丰富的程序员一开始就会很好地设计和构建它。
如果性能确实至关重要（实时？毫秒事务？），那么您需要设计和实施一组基准和工具，以科学地向自己证明您的更改正在使其变得更快。影响性能的变量太多了。
另外，他们还会提出一个经典的程序员借口——“但它运行得很慢，因为我们故意选择了慢速计算机，当我们部署它时，它会运行得更快。”
如果您的同事认为这很重要，请给他一台速度较慢的计算机并让他负责“性能”:-)
Slow computers are not going to help you find your performance problems.
If your test data is only a few hundred rows in a table your db will cache it all and you'll never find badly written queries or bad table/index design. If your server application is not multi-threaded server you will not find that out until you stress test it with 500 users. Or if the app bottlenecks on bandwidth.
Optimization is "A Good Thing" but as I say to new developers who have all sorts of ideas about how to do it better 'I don't care how quickly you give me the wrong answer'. Get it right first, then make it faster when you find a bottleneck. An experienced programmer is going to design and build it reasonably well to start with.
If performance is really critical (real time? millisecond-transactions?) then you need to design and implement a set of benchmarks and tools to scientifically prove to yourselves that your changes are making it faster. There are way too many variables out there that affect performance.
Plus there's the classic programmer excuse they will bring out - 'but it's running slow because we have deliberately picked slow computers, it will run much faster when we deploy it.'
If your colleague thinks its important give him a slow computer and put him in charge of 'performance' :-)
我想这取决于你正在制作什么以及目标受众是什么。
如果您正在为固定硬件（例如，控制台游戏）编写软件，则使用与您将部署的设备相似或相同的设备（至少是测试设备）。
如果您正在开发桌面应用程序或该领域的某些东西，那么可以在您想要的任何机器上进行开发，然后对其进行调整以在所需的最低规格硬件上运行。同样，如果您正在开发内部软件，那么公司想要购买的机器可能会有一个最低规格。在这种情况下，请在快速机器上进行开发（以减少开发时间，从而降低成本）并根据该最低规格进行测试。
最重要的是，在您能拿到的最快的机器上进行开发，并在您将支持的最小或精确的硬件上进行测试。
I guess it would depend on what you're making and what the intended audience is.
If you're writing software for fixed hardware (say, console games) then use equipment (at least test equipment) that is similar or the same as what you will deploy on.
If you're developing desktop apps or something in that realm then develop on whatever machine you want and then tune it afterward to run on the desired min-spec hardware. Likewise, if you're developing in-house software, there is likely to be a min-spec for the machines that the company wants to buy. In that case, develop on a fast machine (to decrease development time and therefore costs) and test against that min-spec.
Bottom line, develop on the fastest machine you can get your hands on, and test on the minimum or exact hardware that you'll be supporting.
如果您在接近最终测试和生产环境的硬件上进行编程，您往往会发现在发布代码时不会出现令人讨厌的意外情况。
我见过足够多的程序员因为他们的机器比大多数用户快得多而导致严重但意想不到的问题。而且，我也看到数据也出现了同样的问题。该代码在一个小数据集上进行测试，然后在一个大数据集上“崩溃”。
开发和部署环境中的任何差异都可能是意外问题的根源。
尽管如此，由于编程既昂贵又耗时，如果最终用户运行缓慢的过时设备，更好的解决方案是在测试时处理它（并安排一些早期测试只是为了检查可用性和定时）。
为什么仅仅因为担心错过潜在问题而削弱程序员呢？这不是一个明智的发展战略。
保罗.
If you are programming on hardware that is close to the final test and production environments, you tend to find that there are less nasty surprises when it comes time to release the code.
I've seen enough programmers get side-swiped by serious, but unexpected problems caused by their machines being way faster than their most of their users. But also, I've seen the same problem occur with data. The code is tested on a small dataset and then "crumbles" on a large one.
Any differences in development and deployment environments can be the source of unexpected problems.
Still, since programming is expensive and time-consuming, if the end-user is running slow out-of-date equipment, the better solution is to deal with it at testing time (and schedule in a few early tests just to check usability and timing).
Why cripple your programmers just because you're worried about missing a potential problem? That's not a sane development strategy.
Paul.
为了热爱 Codd，请使用分析工具，而不是缓慢的开发机器！
for the love of Codd, use profiling tools, not slow development machines!
应该避免优化，这不是给我们带来了 Vista 吗？ :p
但严肃地说，这始终是一个权衡问题。要问自己的重要问题
您的最终用户将使用什么平台？
我可以放弃循环吗？如果我这样做会发生什么？
我同意大多数人的观点，即初始开发应该在您可用的最快或最有效（不一定相同）的机器上完成。但对于运行测试，请在目标平台上运行它，并尽早进行经常测试。
Optimization should be avoided, didn't that give us Vista? :p
But in all seriousness, its always a matter of tradeoffs. Important questions to ask yourself
What platform will your end users be using?
Can I drop cycles? What will happen if I do?
I agree with most that initial development should be done on the fastest or most efficient (not neccesarily the same) machine available to you. But for running tests, run it on your target platform, and test often and early.
取决于您的交货时间。如果您的交付周期为 12 个月，那么您应该以相当快的速度开发盒子，因为您的客户 12 个月后将拥有比当前“平均”更好的“平均”盒子。
随着您的开发周期接近“今天”，您的开发机器应该接近客户设备当前的“平均”速度。
Depends on your time to delivery. If you are in a 12 month delivery cycle then you should develop on a box with decent speed since your customers' 12 months from now will have better "average" boxes than the current "average".
As your development cycle approaches "today", your development machines should approach the current "average" speed of your clients' boxes.
我通常在我能得到的最快的机器上进行开发。
大多数时候我都在运行调试构建，这已经足够慢了。
I typically develop on the fastest machine I can get my hands on.
Most of the time I'm running a debug build, which is slow enough already.
我认为这是一个合理的概念（但也许是因为它对我有用）。
如果我的开发人员工作站太快，我发现我的想法不够彻底，因为重新生成软件映像或将其下载到目标几乎没有时间损失。我想说至少有一半的下载是不必要的，因为我只是想起了在调试代码之前错过的一些东西。
目标机器很可能包含一个节流处理器。如果在嵌入式 MCU 上，每秒的闪存、RAM 和时钟周期只有一半，那么开发人员在设计代码时可能会更加小心。我曾经建议在数据区域（不是在 RAM 中，而是在串行 eeprom 中）中使用字节变量来表示各个记录的长度，并收到答复“我们不需要小气”。几个月后，它们达到了 RAM 上限（128KiB）。我的想法是，对于这个应用程序来说，永远不会有任何大于 256 字节的记录，仅仅是因为没有 RAM 可以将它们复制到其中。
对于服务器应用程序，我认为有一个（很多）性能较低的硬件来测试是一个好主意。两个或四个核心而不是十六个（或更多）。 1.6 GHz isdo 2.8。这样的例子还在继续。由于每个人都与它交谈，服务器通常是系统架构中的瓶颈。这距离您开始为其开发（服务器）应用程序已经很久了。
I think it is a sound concept (but maybe because it works for me).
If my developer workstation is too fast I find I don't think ideas through thorougly enough simply because there is little time-penalty in re-generating the software image or downloading it to the target. I'd say at least half my downloads were unnecessary because I just remembered something I'd missed right before I was going to debug the code.
The target machine could well contain a throttled processor. If - on an embedded MCU - you have half the FLASH, RAM and clock cycles per second chances are developers will be a lot more careful when designing their code. I once suggested byte variables for the lengths of individual records in a data area (not in RAM but in a serial eeprom) and received the reply "we don't need to be stingy." A few months later they hit the RAM ceiling (128KiB). My reflection was that for this app there would never be any records larger than 256 bytes simply because there was no RAM to copy them to.
For server applications I think it would be a great idea to have a (much) lower-performing hardware to test on. Two or four cores instead of sixteen (or more). 1.6 GHz istdo 2.8. The list goes on. A server is usually - due to the very fact that everyone talks to it - a bottleneck in the system architecture. And that is long before you start developing the (server) application for it.