mirror of
https://github.com/tailscale/tailscale.git
synced 2024-11-25 19:15:34 +00:00
4bb2c6980d
testing.AllocsPerRun measures the total allocations performed by the entire program while repeatedly executing a function f. If some unrelated part of the rest of the program happens to allocate a lot during that period, you end up with a test failure. Ideally, the rest of the program would be silent while testing.AllocsPerRun executes. Realistically, that is often unachievable. AllocsPerRun attempts to mitigate this by setting GOMAXPROCS to 1, but that doesn't prevent other code from running; it only makes it less likely. You can also mitigate this by passing a large iteration count to AllocsPerRun, but that is unreliable and needlessly expensive. Unlike most of package testing, AllocsPerRun doesn't use any toolchain magic, so we can just write a replacement. One wild idea is to change how we count mallocs. Instead of using runtime.MemStats, turn on memory profiling with a memprofilerate of 1. Discard all samples from the profile whose stack does not contain testing.AllocsPerRun. Count the remaining samples to determine the number of mallocs. That's fun, but overkill. Instead, this change adds a simple API that attempts to get f to run at least once with a target number of allocations. This is useful when you know that f should allocate consistently. We can then assume that any iterations with too many allocations are probably due to one-time costs or background noise. This suits most uses of AllocsPerRun. Ratcheting tests tend to be significantly less flaky, because they are biased towards success. They can also be faster, because they can exit early, once success has been reached. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com> |
||
|---|---|---|
| .. | ||
| integration | ||
| natlab | ||
| staticcheck | ||
| allocs.go | ||
| clock.go | ||
| log_test.go | ||
| log.go | ||
| resource.go | ||
| tstest.go | ||