Closed dolmen closed 2 weeks ago
Following a discussion on Gophers Slack and a casual inspection of testing
's source code, I don't think b.N
changes during the execution of a benchmark subject. However, I agree with @dolmen that the documentation is ambiguous/misleading in that respect.
I've been a fulltime Go developer for 9 years. I've read the documentation about benchmarks multiple times. I never thought that the whole benchmark function was called multiple times because this is different that Test functions which are called just once. Instead, because of that sentence in the documentation, I thought that b.N
was changed dynamically (with some supposed magic locking that I didn't investigate: after all code coverage via source instrumentation is already magic of go test
).
I have not found this difference in behavior explicitely mentioned in the Go specification. The following sentence speaks about the first evaluation of the range expression, but doesn't mention later evaluations.
The range expression x is evaluated once before beginning the loop, with one exception: if at most one iteration variable is present and len(x) is constant, the range expression is not evaluated.
This is explicitly mentioned: « once before beginning the loop » describe precisely that behavior. I'm not saying this shouldn't be made clearer or something, just it's working as expected and has been for years and changing this would be a language breaking change.
Change https://go.dev/cl/582835 mentions this issue: testing: improve the documentation around b.N
The
testing
documentation clearly mentions that the loop boundary variable might change during execution:I noticed that range over integer loop have different behavior than for with clause loops when the loop boundary is changed by the loop body: https://go.dev/play/p/cObUT32FcXc
I have not found this difference in behavior explicitely mentioned in the Go specification. The following sentence speaks about the first evaluation of the range expression, but doesn't mention later evaluations.
I wonder how a benchmark would be affected by the use of range-over-integer instead of the documented style.
I have seen no clear mention of forbidding the use of range-over-integer with
b.N
for benchmarks. I have not seen either an explicit mention that range-over-int is compatible withtesting.B
benchmarks which makes me wonder if this has been considered. I also did a code search onrange b.N
in the Go repository and the only result is a test in thedatabase/sql
package just added less that 2 months ago by @bradfitz in CL 572119. No tests intesting
.So it would be helpful to have explicit documentation about the use of
b.N
with range-over-integer.If this is in fact an incompatibility, it would be helpful to have a
go vet
alert about use of range-over-int ontesting.B.N
.Go version
go version go1.22.2 darwin/arm64
Output of
go env
in your module/workspace:What did you see happen?
What did you expect to see?