Variable-sized collection generators have exponential sizing issues when composed
Description
Problem
This sort of code can OOM:
Proposed Solution
Reduce the size when generating elements of a collection.
Should this apply to gen/tuple? What about gen/vector with a fixed size?
I'm currently thinking no and yes, respectively
Should we blindly reduce the size, or base it on the number of expected elements (e.g., dividing by the number of expected elements)? Predicting element counts is difficult for the distinct collection generators.
Alternate Approach
Hypothesis allegedly tracks how much randomness has been consumed as a collection is generated, and forces things to be small after it hits a limit.
A similar approach would be difficult for test.check, but maybe not impossible.
One idea is to have generators return, in addition to the rose tree, a number indicating how many bits of entropy they used (and maybe a separate number indicating the minimum amount of entropy they could possibly consume).
Problem
This sort of code can OOM:
Proposed Solution
Reduce the
sizewhen generating elements of a collection.Should this apply to
gen/tuple? What aboutgen/vectorwith a fixed size?I'm currently thinking no and yes, respectively
Should we blindly reduce the size, or base it on the number of expected elements (e.g., dividing by the number of expected elements)? Predicting element counts is difficult for the
distinctcollection generators.Alternate Approach
Hypothesis allegedly tracks how much randomness has been consumed as a collection is generated, and forces things to be small after it hits a limit.
A similar approach would be difficult for test.check, but maybe not impossible.
One idea is to have generators return, in addition to the rose tree, a number indicating how many bits of entropy they used (and maybe a separate number indicating the
minimumamount of entropy they could possibly consume).