-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: BenchmarkMapDelete is non-linear and slow #21546
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
Comments
Change https://golang.org/cl/57611 mentions this issue: |
Looks like the initialization needs to be reworked. I'll take a stab at it today |
Change https://golang.org/cl/57630 mentions this issue: |
I have a reworked benchmark which runs faster and is stable wrt increased benchtime
I'll send a CL shortly |
Change https://golang.org/cl/57650 mentions this issue: |
Move the tophash checks after the equality/length checks. For fast32/fast64, since we've done a full equality check already, just check whether tophash is empty instead of checking tophash. This is cheaper and allows us to skip calculating tophash. These changes are modeled on the changes in CL 57590, which were polished based on benchmarking. Benchmarking directly is impeded by #21546. Change-Id: I0e17163028e34720310d1bf8f95c5ef42d223e00 Reviewed-on: https://go-review.googlesource.com/57611 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
When deleting entries from a map, only clear the key and value if they contain pointers. And use memclrHasPointers to do so. While we're here, specialize key clearing in mapdelete_faststr, and fix another missed usage of add in mapdelete. Benchmarking impeded by #21546. Change-Id: I3f6f924f738d6b899b722d6438e9e63f52359b84 Reviewed-on: https://go-review.googlesource.com/57630 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Note that the ns/op increases as the benchtime goes up. This indicates that the benchmark is not well-formed. Beyond that, it causes problems because (1) minor performance changes that trigger a change in the number of iterations appear to be significant performance changes and (2) when the number of iterations that fits in benchtime is on the edge it causes a bimodal ns/op distribution.
Note also that it takes 12s to run a 1s benchmark. Ouch.
IIRC, some other recently added map benchmarks share these problems. (They also should have been added to mapspeed_test.go instead of map_test.go.)
cc @randall77 @huguesb @bcmills
The text was updated successfully, but these errors were encountered: