Repository navigation
Slow incremental run when single module has errors #4135
Description
mypy -i is slower than expected in the following scenario:
- Check out fresh mypy repository
- Create tiny module
mypy.xthat generates an error:echo '1 + ""' > mypy/x.py - Run
mypy -i mypy- This takes a while, generates an error for
mypy/x.pyas expected
- This takes a while, generates an error for
- Run
mypy -i mypy- This is as slow as the previous run, but caching should make this much faster
Activity
JukkaL commentedon Oct 19, 2017
@gvanrossum in #4130 (comment):
gvanrossum commentedon Nov 7, 2017
Adding topic-daemon label because this impedes one of the important use cases for the daemon (quickly rechecking code with errors).
JukkaL commentedon Nov 17, 2017
This is blocking progress in fine-grained incremental mode. ASTs can't be reused when there is an error. In fine-grained incremental mode we want to cache every module that has no blocking errors. I'll try to fix or work around this.
JukkaL commentedon Nov 20, 2017
I've worked around this in my local branch (but have not fixed the underlying issue).
gvanrossum commentedon Dec 6, 2017
I've got a clue about why this is happening: in build.py, in State.write_cache(), on line 1943, there's a check for self.manager.errors.is_errors(). But this returns True when there was an error in any previous file! And then two lines down we actually call delete_cache(). (This was added recently in PR #4045.)
What we actually need is a little different -- we want to check if the current SCC or any of its dependents has errors.
Don't delete cache on all errors -- only on errors in dependencies
Don't delete cache on all errors -- only on errors in dependencies
Only delete cache errors in dependencies -- take two
Fix incremental speed regression (#4331)