-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Remove hook proxy cache #2073
Remove hook proxy cache #2073
Conversation
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 think that your approach looks clever & correct. But I do want to double check, given that this is an increase in complexity - did you consider just removing the _fs2hookproxy
cache? My (very limited) experiments show that the cache doesn't improve performance at all.
@@ -481,6 +481,7 @@ def _makefile(self, ext, args, kwargs): | |||
ret = None | |||
for name, value in items: | |||
p = self.tmpdir.join(name).new(ext=ext) | |||
p.dirpath().ensure_dir() |
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.
This doesn't seem wrong or anything, but is it actually relevant to this code change?
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.
No, just that I needed this to make the test easier. Now one can use sub-directories in the keys to testdir.makepyfile
(actually any "make*" functions):
testdir.makepyfile(**{
'foo/bar/foobar.py': 'print("hello world")',
})
I did consider, and I thought that since So I decided to make a benchmark to see if it was true. I wrote this script which creates an arbitrarily nested directory tree with tests on it. Running:
Generates a tree 4 levels deep, 6 folders per level and 10 test files each, without any conftest.py files (that's what the last Here are the results I got on my Windows box:
The timings were obtained by running So it seems there's some gain by using the cache (specially when there are conftests), but they see minimal in my opinion. That 9-10s difference with 30000 tests doesn't seem relevant, after all with 30000 tests that test suite, if it were real, would take several minutes to run (if not hours). It takes 76s to run the full suite, and those are all tests with just Unless there's something wrong with my testing, I agree that we could just take out that cache. |
e1a75bd
to
56e8274
Compare
Cool! Really nice experiment. |
great analysis. This really calls for removing the cache. If a caching layer does not provide measurable benefit it should go. There are two hard CS problems: naming, caching and off-by-one errors. |
Thanks @hpk42! I will update the PR to remove the cache then. 👍 |
56e8274
to
5f50343
Compare
5f50343
to
fec1c7b
Compare
fec1c7b
to
81528ea
Compare
Changed target to |
Fixes #2016
@hpk42 I would appreciate if you could take a look as you probably know the most about that part of the code. This comment contains the full description of my diagnosis of the problem.
cc @d-b-w