-
-
Notifications
You must be signed in to change notification settings - Fork 147
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
Serious performance issues from 1.12 and up #191
Comments
Seconded! How about we actually make I suppose the only downside is that it having an |
I'm happy to open up a PR for the suggestion from @tomage. I'm assuming the intention is to prevent using it as a context manager. If the authors can verify this, I believe this will be an appropriate solution that doesn't change UX |
Thanks @wesleykendall and @tomage for writing! Completely agree this small feature is not worth the large slowdown. I've opened a PR with @tomage's suggestion and it seems to do the trick: #192 Would appreciate a review of you both if possible before releasing. FTR I'm OK with removing this if #192 introduces then a regression for someone else. 👍 |
The addition of this line (6587f79) that checks if one is inside a context manager caused our test suite to run over 3x slower (5 minutes to 17 minutes).
I understand the desire to report a more useful error message when a user tries to use it as a context manager, but the stack inspection on every patch causes a slowdown that makes pytest-mock unusable for us, especially since our test suite has hundreds of test files. Our observations indicate that the performance degradation is even more pronounced when using pytest-xdist.
One can observe the performance impacts in a simple test example:
In a test.py file:
Install
pytest-repeat
andpytest-mock==1.12.0
total runtime = 4.45s
Install
pytest-mock==1.11.2
total runtime = 2.28s
Now do the same experiment with
pytest-xdist
with 1.12:
total runtime = 6.67s
with 1.11.2:
total runtime = 3.18s
Although this test case doesn't have performance impacts as pronounced as our test suite, which has hundreds of files and tests thousands of python files, it is still upwards of a 2x slowdown.
Can this check be removed altogether? IMO it is not worth it to slow down a test suite this much for a more useful error message in a few rare circumstances. Would it be possible to instead try to catch the unhelpful error message and then re-raise it as something helpful instead if this check is really aiding in the UX of the library? Thanks for your consideration
The text was updated successfully, but these errors were encountered: