如何量化你的“慢”开发机？
（请提供这个重复的问题。我很失望我找不到它。）
我的开发机器“慢”。我“等了很多”。
决策者向我询问，他们希望帮助公平、准确地衡量这一时间。如何量化您在计算机上等待的时间（编译期间、每天等待应用程序打开等）。
有没有软件可以有效地报告此类事情？是否有一个操作系统指标（I/O、页面文件交换频率等）可以特别好地捕获和传达这一点？您建议我测试某种基准？
编辑：我正在编写 C#（主要是 ASP.NET）。
( Please provide the question this one duplicates. I'm disappointed I couldn't find it. )
My development machine is "slow". I wait on it "a lot".
I've been asked by decision makers who want to help to fairly and accurately measure that time. How do you quantify the amount of time you spend waiting on the computer (during compiles, waiting for apps to open every day, etc).
Is there software which effectively reports on this sort of thing? Is there an OS metric (I/O something something, pagefile swapping frequency, etc, etc) that captures and communicates this particularly well? Some sort of benchmark you'd recommend me testing against?
EDIT: I'm writing C# (mostly ASP.NET).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这里有一个指标可能会给一些高层留下深刻的印象：测量构建应用程序所需的平均时间，以及每天执行此操作的次数。例如，我们最终每天构建约 100 个，每个构建 60 秒。
现在，在一台可能更快的机器上测量平均构建时间（例如每次构建 30 秒）。
此时，您可以看到拥有“更快”的机器将为您节省多少时间。每个开发人员，每天。乘以开发人员的数量以及一个月中的天数，您可以看到这与向团队中添加其他开发人员相比有何影响。
是的，我知道，在团队中添加更多人员时还有其他考虑因素，但这将为您提供与“高层”相关的粗略比较。例如：如果我们都有更快的机器，我们在构建上花费的时间就会更少，相当于多一个开发人员。
另一方面，您应该对升级每个人的机器的成本进行良好的估计。
现在，如果可以的话，您应该对多个“更快”的机器进行这种类型的比较，以确定它们的相对性能，并可能确定您面临的瓶颈（RAM、CPU 与 I/O？）。
最后，我个人的看法是，虽然进行了此类流程以及与利益相关者的后续讨论（可能需要一段时间），但您可以让每个人都拥有更大/更多的监视器。这是一个相对便宜的升级（当然，如果您选择 52 英寸 LCD 显示器，那么价格并不便宜，对吧？）并且更多的显示器空间确实可以提高生产力（专业提示：还可以提高员工士气，从而提高生产力）
。HTH
Here's one metric that may impress some higher ups: measure the average time it takes to build your application, and how many times you do that per day. For instance, We ended up with ~100 builds a day @ 60 secs each.
Now, measure the average build time on a presumably faster machine (say 30 secs per build).
At this point you can see how much time it would save you to have the 'faster' machine. Per-developer, per-day. Multiply by the number of developers, and the days in a month and you can see how this stacks against adding another developer to the team.
Yes, I know, there are other considerations when adding more people to a team, but this will give you a rough comparison that 'higher ups' can relate to. For instance: if we all had faster machines, we would spend less time on the builds, comparable to one extra developer.
On the other side, you should provide good estimates of the cost of upgrading everyone's machine.
Now, if you can, you should run this type of comparison against multiple 'faster' machines to determine their relative performance and perhaps individuate which bottlenecks you are facing (RAM vs CPU vs I/O ?).
Finally, my personal take is that, while this sort of process and the following discussion with the stakeholders takes place (and it may take a while), you could get everyone bigger/more monitors. That's a relatively cheap upgrade (of course, not that cheap if you go for 52" LCD monitors, right?) and more monitor-estate does improve productivity (protip: also improves employees morale, which, in turn, improves productivity).
HTH
关闭 FireFox 以获取一些内存。添加内存。对我帮助很大。
Close FireFox to gain some memory. Add RAM. Helped me a lot.
取决于您的工作环境。例如，在 Visual Studio（C++，2005）中，您可以执行定时构建，以便 IDE 在常规构建输出后打印经过的时间。
Depends on your work environment. E.g. in Visual Studio (C++, 2005) you can do timed builds, such that the IDE prints the elapsed time after the regular build output.
当您没有任何东西可以衡量/比较时，量化就很困难。如果您的开发盒需要 12 分钟来编译一个包含 100,000 行代码的项目，而没有任何其他开发盒来衡量，那么您不知道这是好是坏。也许 12 分钟 100,000 行实际上就不错了？
衡量它对你没有帮助，当然也对你的决策者没有帮助。考虑; “是的老板，我们的项目平均编译需要十二分钟。”老板说； “好吧，这正常吗？”你不知道。
计算机硬件很便宜。查看开发框并考虑要求决策者投入一些现金以提高其性能。如果您平均每天编译 5 次，并且平均每次编译需要 12 分钟，那么每天就损失了一个小时 - 每周总共损失了 5 个小时。升级一些 RAM 或 CPU 的成本非常值得。
Quantification is difficult when you don't have anything to measure/compare against. If your dev-box takes 12 minutes to compile a project of 100,000 lines of code without any other dev-box to measure against you have no idea if this is good or bad. Maybe 12 minutes for 100,000 lines is actually good?
Measuring it won't help you and it certainly won't help your decision makers. Consider; "Yes boss, it takes an average of twelve minutes to compile our project." The boss says; "Ok, is that normal?". You have no idea.
Computer hardware is cheap. Look at the dev-box and consider asking the decision makers to throw some cash at it to improve its performance. If you compile on average 5 times a day and it takes an average of 12 minutes a compile, that's a lost hour every single day - adding up to 5 lost hours a week. Well worth the cost of some RAM or a CPU upgrade.
对我来说，慢速机器不会像意外变慢那样降低生产力 - 如果每次按 F5 时机器会在 12 分钟内编译整个解决方案，那么是解决方案出现问题，而不是机器出现问题。除此之外，12分钟我没有问题，我可以起床休息一下。当您知道并控制休息时长时，休息实际上是件好事。
我发现最大的生产力杀手是这些协作软件，它们随意开始扫描病毒（或安装更新） - 必须坐在那里等待是一件痛苦的事情。
To me, a slow machine does not kill productivity as much as unexpected slowing down does - if the machine compiles the whole solution in 12 minutes every time you press F5, the solution has some problem, not the machine. Beside that, I don't have problem with 12 minutes, I can get up take a break. It's actually good to take a break when you know and have control on how long the break will be.
What I found the most productivity killer are these cooperate software that start scanning virus (or install updates) at their will - having to sit there and wait is a pain of ass.