如何量化你的“慢”开发机器？

Question

（请提供一个重复的问题。我很失望，我找不到它。）

我的开发机器“很慢”。我等了很多次。

决策者曾要求我帮助公平准确地衡量时间。如何量化您在计算机上等待的时间（在编译期间，等待应用程序每天打开等）。

是否有软件可以有效地报告此类事情？是否存在操作系统指标（I / O某些东西，页面文件交换频率等等），这些特别好地捕获并传达了这一点？你推荐我测试的某种基准测试？

编辑：我正在编写C＃（主要是ASP.NET）。

Answer 1

这是一个可能会给某些更高层次打动的指标：衡量构建应用程序所需的平均时间，以及每天执行此操作的次数。例如，我们最终每天约有100个版本，每个版本60秒。 现在，测量一个可能更快的机器的平均构建时间（比如每个构建30秒）。

此时你可以看到有多少时间可以让你拥有“更快”的机器。每个开发人员，每天。乘以开发人员的数量和一个月内的日子，您可以看到这是如何反对向团队添加其他开发人员的。 是的，我知道，在向团队中添加更多人员时还有其他一些考虑因素，但这会给你一个粗略的比较，即'高层'可以与之相关。例如：如果我们都拥有更快的机器，我们将花费更少的时间在构建上，与一个额外的开发人员相比。

另一方面，您应该提供升级每个人机器的成本的良好估计。

现在，如果可以的话，你应该对多个“更快”的机器运行这种类型的比较，以确定它们的相对性能，并且可能个别化你面临的哪些瓶颈（RAM与CPU对I / O？）。

最后，我个人认为，虽然这种过程以及与利益相关者的以下讨论会发生（并且可能需要一段时间），但您可以让每个人都更大/更多的监视器。这是一个相对便宜的升级（当然，如果你选择52英寸液晶显示器，并不是那么便宜，对吧？）更多的显示器产能确实提高了生产力（protip：也提高了员工的士气，从而提高了工作效率）。 / p>

HTH

Answer 2

关闭FireFox以获得一些内存。添加RAM。帮助了我很多。

Answer 3

取决于您的工作环境。例如。在Visual Studio（C ++，2005）中，您可以进行定时构建，以便IDE在常规构建输出之后打印经过的时间。

Answer 4

当您没有任何可衡量/比较的东西时，量化很困难。如果您的开发箱需要12分钟来编译一个包含10万行代码的项目而没有任何其他开发框来衡量，那么您不知道这是好还是坏。 10万行可能12分钟实际上好吗？

衡量它对你没有帮助，它肯定不会帮助你的决策者。考虑; “是老板，编制我们的项目平均需要12分钟。”老板说; “好的，这是正常的吗？”你不知道。

计算机硬件很便宜。看看开发盒，考虑让决策者向它投入一些现金以改善其性能。如果你平均每天编译5次并且编译平均需要12分钟，那么每天都会丢失一小时 - 每周最多增加5个小时。非常值得一些RAM或CPU升级的成本。

Answer 5

对我来说，慢速机器不会像意外放慢速度那样降低生产率 - 如果机器在每次按F5的情况下在12分钟内编译整个解决方案，解决方案就有问题，而不是机器。除此之外，12分钟我没有问题，我可以起床休息一下。当你知道并控制休息时间时，休息一下真的很好。

我发现最具生产力的杀手是这些合作软件，他们会随意开始扫描病毒（或安装更新） - 不得不坐在那里等待屁股是痛苦的。