-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
mypy is slow when type checking torch #17919
Comments
If this is accurate, maybe the fscache exception handling is really slowing us down in the mypyc build. mypyc: interpreted: |
Mypy detects an import cycle with 945 modules. Overall 1380 files were parsed, so 68% of processed files are in this one SCC. I've seen this pattern in other third-party packages as well -- the majority of the implementation is a single SCC. A potential way to make the SCC smaller would be to process imports lazily in third-party modules (where this is possible, since errors aren't reported). It may be tricky to implement though, but I'll think about it more. |
Yeah, lazy import resolution could be a massive perf win |
#17924 is the issue for tracking lazy resolution Jukka's times in #17920 (comment) are much better than mine. #17948 is the issue for tracking performance improvements in my work environment. |
We use a lot of torch at work, performance is probably the biggest reason folks at work switch to a different type checker.
The text was updated successfully, but these errors were encountered: