Add note on potential go benchmark optimisations #781
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note was italicized and didn't have a colon. This didn't match the other case of a note in the itegers chaper which was.
Added a note on go optimizing benchmarks and a link to Dave Cheney's blog post on how to write benchmarks for how to make sure it doesn't. This optimization seems rare from reading issues online but does happen so warning would be good to let people know.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
To address issue #694, I added a note warning that Go can sometimes optimize functions being benchmarked, leading to inaccurate results. From research this issue seems to be rare, but it is probably still a good idea to warn users about it. There are several related issues in the Go repository, and people are looking for guidance from the Go team. I believe a warning is sufficient for now, as the benchmarks in the lesson follow the same practices as those in the Go documentation and most other codebases. However, this may need to be revisited in the future if best practices change. I linked a blog post from Dave Cheney in the warning so that people could read more and see how to address this issue if it comes up for them.