（请提供这个重复的问题。我很失望我找不到它。）
我的开发机器“慢”。我等待它“很多”。
决策者曾向我提出要求，他们希望帮助公平、准确地衡量那段时间。您如何量化您在计算机上等待的时间（编译期间、每天等待应用程序打开等）。
是否有软件可以有效地报告这类事情？是否有一个操作系统指标（I/O 某事、页面文件交换频率等）可以很好地捕获和传达这一点？您建议我测试的某种基准？
编辑：我正在编写 C#（主要是 ASP.NET）。
问问题
470 次
5 回答
2
这是一个可能会给一些高层留下深刻印象的指标：衡量构建应用程序所需的平均时间，以及您每天这样做的次数。例如，我们最终每天构建约 100 个，每个构建时间为 60 秒。现在，在可能更快的机器上测量平均构建时间（比如每次构建 30 秒）。
此时，您可以看到拥有“更快”的机器将为您节省多少时间。每个开发人员，每天。乘以开发人员的数量，以及一个月中的天数，您可以看到这与向团队中添加另一个开发人员有何不同。是的，我知道，在向团队添加更多人时还有其他考虑因素，但这会给你一个粗略的比较，“高层”可以与之相关。例如：如果我们都有更快的机器，我们将花费更少的时间在构建上，相当于一个额外的开发人员。
另一方面，您应该提供对每个人的机器升级成本的良好估计。
现在，如果可以的话，您应该对多台“更快”的机器进行此类比较，以确定它们的相对性能，并可能区分您面临的瓶颈（RAM vs CPU vs I/O？）。
最后，我个人的看法是，虽然发生了这种过程以及与利益相关者的以下讨论（可能需要一段时间），但您可以让每个人都拥有更大/更多的监视器。这是一个相对便宜的升级（当然，如果你选择 52 英寸 LCD 显示器，就不会那么便宜，对吧？）而且更多的显示器空间确实提高了生产力（提示：也提高了员工的士气，这反过来又提高了生产力）。
高温高压
于 2010-03-24T23:58:26.083 回答
1
关闭 FireFox 以获得一些内存。添加内存。帮了我很多。
于 2010-03-24T23:09:18.717 回答
0
取决于你的工作环境。例如，在 Visual Studio (C++, 2005) 中，您可以进行定时构建，这样 IDE 会在常规构建输出之后打印经过的时间。
于 2010-03-24T16:25:04.383 回答
0
当你没有任何东西可以衡量/比较时，量化是很困难的。如果您的 dev-box 需要 12 分钟来编译一个包含 100,000 行代码的项目，而没有任何其他 dev-box 来衡量，那么您不知道这是好是坏。也许 12 分钟 100,000 行实际上是好的？
衡量它不会帮助你，它肯定不会帮助你的决策者。考虑; “是的，老板，编译我们的项目平均需要十二分钟。” 老板说；“好吧，这正常吗？” 你不知道。
电脑硬件很便宜。查看开发盒并考虑要求决策者投入一些资金以提高其性能。如果您平均每天编译 5 次，并且每次编译平均需要 12 分钟，那么每天都会浪费一个小时 - 每周总共浪费 5 个小时。非常值得一些 RAM 或 CPU 升级的成本。
于 2010-03-24T16:39:19.410 回答
0
对我来说，一台缓慢的机器不会像意外减速那样降低生产力——如果机器每次按 F5 时都会在 12 分钟内编译整个解决方案，那么解决方案有问题，而不是机器。除此之外，12分钟我没有问题，我可以起床休息一下。当您知道并且可以控制休息时间长短时，休息一下实际上是件好事。
我发现最大的生产力杀手是这些合作软件，它们可以随意开始扫描病毒（或安装更新）——不得不坐在那里等待是一种痛苦。
于 2010-03-24T16:58:33.677 回答