Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core: round metric savings to remove false precision #15721
core: round metric savings to remove false precision #15721
Changes from all commits
1dca7bf
d6cea5d
f632bb0
68eb7ce
c7c49aa
9757c3a
34b4779
b83a126
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gah, I can see the appeal of using
Math.floor()
in examples like this. Because it's potential savings we don't want to overestimate the value. Agreed with @connorjclark that rounding 199 to 100 isn't great, but so is overpromising the savings by 2x here.OTOH using a precision of 50 and
Math.round()
means the rounded value is only ever a max of 25ms away from the original value. To do the same withMath.floor()
we'd have to drop the granularity to 25, which may be getting too precise again.IMO in terms of purity (don't overpromise savings you won't be able to get)
Math.floor()
makes the most sense. However in practice, considering the chosen granularity levels and the lack of actual accuracy in the initial estimate, I think it probably doesn't matter, and soMath.round()
works fine and arguably better.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think the case I'm more worried about is this audit score goes from 0.5 to 1 just because of 25.x ms of savings. Perhaps a follow-up PR could introduce some minimum threshold for that condition as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, one of the reasons this PR exists