-
Notifications
You must be signed in to change notification settings - Fork 161
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
Add ability to customize max default SizeRange via env var. #338
Add ability to customize max default SizeRange via env var. #338
Conversation
The implementation directly accesses Config::default() from SizeRange::default(). I don't love the implementation for two reasons - It clones the full config on every call to SizeRange::default() - It is hard to test. However, it does achieve the goal. I am open to better ideas!
Thanks! Personally, I'd be in favor of changing the behavior of When using I would also not oppose reducing the default. |
I've added the changes I proposed here https://github.com/nipunn1313/proptest/compare/nipunn/proptest_max_size...tzemanovic:proptest:nipunn/proptest_max_size_2?expand=1. Please lmk if you're happy with the changes and I can push them back here |
I'll give this a look this evening after work. If it's reusing existing config mechanisms rather than plunking env vars in the impl of Default im more in favor |
Agh I never published my comment. I didn't realize what the original proposal was. I'm fine with the original PR opened here. Tomas for your alternative changes, I'd want the default impl of size range to use the config contextualization rather than directly reading env vars. That way we isolate all env-based configuration to just Config. Whats the rationale behind removing the contextualization from |
@matthew-russo My main motivation is to remove the cloning from
|
If this is perf related are there any numbers showing removing the clones improves test runtime? I'd be pretty surprised if the config generation is where times being spent. I haven't spent much time with this area of the code though. This would change the behavior of existing users which I'm skeptical of doing without a breaking version change. |
On my machine it is slightly better than the previous impl that was cloning the whole The change itself however is not externally a breaking change. Even though the behavior of |
I took a look over this myself and just wanted to weigh in with my opinion
I read through @tzemanovic 's pr and though I agree with some of the motivation I think there's some things to consider
I hope this helps move this forward in some direction. Just to summarize
I'll be on vacay for a couple weeks so that's all input I have for the time being |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm fine merging as-is
unrelated change broke nightly build - fixing it in #389 |
I merged master here to reconcile the merge conflicts with master. Should be good to go! |
Nightly build seems broken for an unrelated reason. will try to fix that today and then get this merged |
The implementation directly accesses Config::default() from SizeRange::default().
I don't love the implementation for two reasons
However, it does achieve the goal. I am open to better ideas!
We could avoid the clone by changing the behavior of
Config::default()
(perhaps (&Config)::default() - or by makingDEFAULT_CONFIG
lazystatic public.Fixes #320
After implementing this, I am starting to feel more partial to the alternate approach of reducing the default max sizerange drastically to 0..8 and making people increase it manually via a non-default strategy - if that's the behavior they want. The perf of nested vecs snowballs out of control quite fast IMO and a bit of a surprise.