-
Notifications
You must be signed in to change notification settings - Fork 37
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
Shrinker performance benchmark #177
Conversation
1bf5c8a
to
230eb76
Compare
I have rebased this benchmark PR on top of the merged test PRs. We still have a few tests printing to stdout, so to avoid garbling the two outputs I changed the program to write the results to a file - for now just hard-coded to For your viewing pleasure, below follows the output from a fresh run. The situation is (unsurprisingly) the same as I described above in the fall - but PRs #235 and #240 start to change that:
|
This PR adds a shrinker benchmark.
It iterates the (factored) shrinker tests in QCheck_tests.ml and QCheck2_tests.ml in pairs.
For each such pair of tests we measure
Q1/s
andQ2/s
#succ
#att
This is iterated across several seeds to make sure observations hold across more than one random run.
Finally we add up the timings to spot general trends.
Overall, the benchmark gives a reasonable idea of the state of affairs (see output below):
lists shorter than 4332
fold_left fold_right uncurried
in one iteration, whereas QCheck spends 28.631 secs on only 125 successful shrink attempts out of 27750 onfold_left test, fun first
in another iteration.The benchmark starts to drill the framework:
I've therefore drafted (QCheck) performance improvements that will make such hacks unnecessary. I'll commit them separately.