provide a flag to control the minimum number of iterations
authorAdam Simpkins <simpkins@fb.com>
Fri, 1 Mar 2013 05:33:29 +0000 (21:33 -0800)
committerJordan DeLong <jdelong@fb.com>
Tue, 19 Mar 2013 00:08:02 +0000 (17:08 -0700)
commitf0abc60e82eb1dd1340eed6085f2307037ce48fe
tree0093e0018558fab3f45f91d195a643799a0bb69d
parent8c89c7ddb2690e391521420253724a4ab1fb237b
provide a flag to control the minimum number of iterations

Summary:
Add a --bm_min_iters flag to control the minimum number of iterations
that the benchmark code starts with on each epoch.

This can be used on benchmarks that test very cheap operations, but take
a long time to set up.  Otherwise the benchmark code may have to retry
many times before it hits a large enough number of iterations to get a
meaningful result, and each time it still pays the fixed setup cost.

This also helps with benchmarks when some of the setup cost cannot be
hidden with BenchmarkSuspender for some reason.  --bm_min_iters can be
set to a large enough value so that the extra startup cost will not
affect the measurements too much.

Test Plan:
Used this with the thread local stats benchmark.  During setup/cleanup,
this benchmark starts and synchronizes with many threads.  The entire
setup time cannot be reliably hidden with BenchmarkSuspender; the
synchronization between the threads takes a relatively long time
compared to the cost of the operation being benchmarked.  --bm_min_iters
allows a relatively high number of iterations to be used, masking this
cost.

Reviewed By: rajat@fb.com

FB internal diff: D723304
folly/Benchmark.cpp