多少性能提升是值得/值得注意的?

发布于 2024-07-16 20:09:07 字数 215 浏览 8 评论 0原文

每个人对何时何地提高性能都有自己的看法,所以这里不感兴趣,但我想知道什么时候性能增益值得提升(比如从分支发展到主干,或者足以放在一些进展上)报告或其他)。

例如,我的经验法则是 10% 的性能提升是值得注意的,但 5% 没什么特别的(当然加起来它们可能是值得的)

注意:因为没有标记此 wiki 的正确答案,但我确实觉得在做出性能决策时对这个主题发表意见很有用

Everyone has their views on when and where to increase performance, so that's not of interest here, but I was wondering at what point a performance gain becomes worthy of promotion (say from branch development into the trunk, or enough to be placed on some progress report or whatever).

For example my rule-of-thumb is a 10% performance boost is noteworthy, but a 5% is nothing special (of course added up they may be worthy though)

Note: as there is no correct answer marking this wiki, but I do feel having opinions on the subject is useful when making decision about performance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

泅渡 2024-07-23 20:09:07

我宁愿使用绝对值。 1 毫秒的 20% 不是你关心的事情。 但一小时的 2% 已经相当可观了。

I'd rather use absolute values. 20% of 1 ms isn't something you care about. But 2% of an hour is pretty impressive.

人│生佛魔见 2024-07-23 20:09:07

如果性能的提高给系统带来了新的质量,那么就值得一提。 否则通常没人关心。

例如,如果系统过去在加载合理但高于通常数量的数据时工作速度明显缓慢,并且您已经修复了此问题,则值得一提,因为那些加载大量数据的用户将从改进中受益。

If increased performance adds a new quality to the system, it's worth mentioning. Otherwise noone usually cares.

For example, if the system used to work noticeably slow when loaded with a reasonable but above usual amount of data and you've fixed this problem it's worth mentioning because those users who load huge amounts of data will benefit from the improvement.

清风疏影 2024-07-23 20:09:07

对于大 n 的 O(n) 到 O(log n) 算法改进非常很好。

O(n) to O(log n) algorithm improvement for big n's is very good.

命硬 2024-07-23 20:09:07

我认为这也取决于代码的优雅/可读性。 如果某个特定的更改感觉像是一个更正确的解决方案,消除了代码中的一些愚蠢之处,那么如果它还提高了性能,那么它就是“值得的”。 然而,如果某个特定的更改纯粹是为了性能而设计,并降低了代码的可读性或可维护性,那么最好是一个相当好的提升,使其值得……也许 50%。

I think it depends on the elegance/readability of the code too. If a particular change feels like a more correct solution, eliminating some stupidity in the code then if it also improves performance at all, it's "worthy". However, if a particular change is designed purely for performance, and decreases code readability or maintainability, then it better be a pretty good boost to make it worthy... maybe 50%.

埋情葬爱 2024-07-23 20:09:07

这取决于。

如果这 5% 转化为节省的资金,例如在大型服务器场上,那就值得注意了。

如果最终用户的计算机上速度提高了 5%(而用户甚至不会注意到),那么就不会。

It depends.

If those 5% translate into money saved e.g. on a big server farm it would be noteworthy.

If it is 5% faster on an end user's computer, who wouldn't even notice, then not.

飘落散花 2024-07-23 20:09:07

这取决于上下文。

在需要实时播放视频的应用程序中,每帧 1 毫秒的改进可能是每秒 30 帧(这是视频剪辑的常见速率)与每秒 29 帧(视觉上看起来)之间的差异。由于丢帧而变得更糟)。

在另一个过夜运行的应用程序中,两个小时与三个小时可能不会产生任何实际差异(但运行时对数据库造成的负载可能非常显着 - 相反,请对其进行优化!)。

It depends on context.

In an application that needs to play video in real-time, a 1ms improvement per frame can be the difference between 30 frames per second (which is a common rate for video clips) to 29 frames per second (which would look - visually - much worse due to dropping frames).

In another application that runs over-night, two hours vs. three hours may not make any real world difference (but the load caused to the database while running can be very significant - optimize that instead!).

卖梦商人 2024-07-23 20:09:07

这是一个简单的测试:给某人未优化的系统并要求他们使用它。 给他们优化的系统并要求他们使用它。 询问他们是否能分辨出其中的区别,以及他们最喜欢哪一个。 (确保这是双盲测试并且系统在其他方面是平等的)。 如果人们更喜欢优化后的系统,那么就值得大声喧哗。

这是一个更简单的测试:你能分辨出区别吗? 如果做不到,那就不值一提了。 (另一方面,小的改进会不断积累)。

Here's a simple test: give someone the unoptimized system and ask them to use it. Give them the optimized system and ask them to use it. Ask them if they can tell the difference, and which they like best. (be sure that it's a double-blind test and that the systems are otherwise equal). If people like the optimized system more, it's worth making noise about.

Here's a simpler test: can you tell the difference? If you can't, then it's not worth mentioning. (on the other hand, small improvements accumulate).

余厌 2024-07-23 20:09:07

基本上当它是一个数量级或更好的完整工作单元时。

  • 小时到分钟批处理
  • 分钟到秒用户触发的批处理、安装、构建
  • 秒到一秒用户触发的过程
  • 一秒到即时 >用户触发的流程

Basically when it is an order of magnitude or better for a complete unit of work.

  • Hours to minutes batch processes
  • Minutes to seconds user triggered batch processes, installs, builds
  • Seconds to a second user triggered processes
  • A second to instant user triggered processes
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文