我职业生涯的开始是软件性能工程师。我们对不同的代码实现、多个操作系统、硬件系统和各种网络配置进行了全面的测量。令人惊讶的是，人们经常想要优化那些在整体性能中并不是瓶颈的东西。真正的瓶颈在测量后通常很容易看到，而且通常很容易解决。但在这一体系内工作也很艰难。它很乏味、耗时，并且涉及大量实验性的计算机科学工作。此外，它还是一个成本中心（团队必须拿出部分预算来支持性能工程），尽管我们有成排的设备用于构建和测试端到端系统，但大多数开发团队想要的是让我们给他们所有的脚本和测量工具，让他们自己“做”（他们不想拿出预算）
源讨论《Helldivers 2》开发团队将安装大小从154GB减少到23GB原帖 284 条评论 · 导入时统计> 根据他们最新的游戏数据测量，开发者已经确认，上周只有11%的玩家使用机械硬盘，他们将看到任务加载时间在最坏情况下只增加几秒钟。此外，帖子中还提到："《Helldivers 2》中大部分加载时间是由于关卡生成，而不是资产加载。这个关卡生成与从磁盘加载资产是并行进行的，因此是决定加载时间的主要因素。" 对我来说，他们接受如此高的成本（安装大小超过150GB！）却完全没有验证这是否必要，这似乎很奇怪！ 我预计这个故事永远不会被详细讲述到能满足好奇心的程度，但从外部来看，这种优化既有可能又可接受，这确实显得很奇怪。
完整原文把你的经验，加入这段讨论。
这听起来像是有趣的工作，但也像一个管理角色的案例研究，即“清除道路”并处理大部分内部倡导和权谋，这样一线工程师就不必处理这些事情。
完整原文这是因为为自己在微基准测试中获得5倍性能提升而自夸感觉很好，而且在年度评估中看起来也不错。 > 但这也是组织内部艰难的工作。它很乏味、耗时，并且涉及大量实验计算机科学工作。此外，它是一个成本中心（团队必须拿出部分预算来支持性能工程），即使我们有成排的设备用于构建和测试端到端系统，大多数开发团队想要的是给我们所有的脚本和测量工具，让他们自己“自己做”，这样他们就不必拿出预算。 预算和目标不一致是良好工程的噩梦。我见过一些绝对愚蠢的事情，比如外包一个简单的网站托管给我们，因为客户宁愿雇佣第三方来购买域名并放置一个简单的网站（一些广告），而不是与他们自己的安全人员打交道…
完整原文在一家在线服务公司，性能团队可以是净收益而非“成本中心”。我在工作的性能团队经常发现可量化的节省，这足以证明他们的成本是值得的。 偶尔会有巨大的错误，但大部分情况下是千刀万剐——很容易在这里或那里犯0.1%的回归错误，而每个性能工程师有数百名其他工程师。在大型部署的机群中，每周几次挽回这些0.1%的损失是有价值的。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。