You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that many people initially run plain mypy and then start using mypy -i but find that the first such run is not any faster than a plain run. This is understandable because it needs to warm the cache first.
We could alleviate this issue by just always writing the cache (perhaps allowing this feature to be turned off for special scenarios but having it on by default). This might cost a little bit of extra run time -- IIRC I once measured the cost of writing the cache and it was in the 5-10% range.
The text was updated successfully, but these errors were encountered:
I'm torn about that. Historically -i mode has had a lot of instabilities around edge cases, which would make this problematic -- but some of that is because it's not on by default, so maybe enabling it by default is better because it'll get more testing. Also, at Dropbox it suffered from not flushing the cache when the mypy version changes, but that's been fixed recently (#2992).
Writing the cache always seems reasonable to me, since the performance overhead is pretty minor but the potential speedup from being able to use -i is significant. Turning it off manually could be useful at least for CI jobs that won't ever run mypy twice.
I feel like turning -i on by default is a little risky, since it has historically been unstable and we don't have very good CI around it yet. Regressions to -i can still slip through quite easily. I'd suggest we wait until we have better testing around it.
I've noticed that many people initially run plain
mypy
and then start usingmypy -i
but find that the first such run is not any faster than a plain run. This is understandable because it needs to warm the cache first.We could alleviate this issue by just always writing the cache (perhaps allowing this feature to be turned off for special scenarios but having it on by default). This might cost a little bit of extra run time -- IIRC I once measured the cost of writing the cache and it was in the 5-10% range.
The text was updated successfully, but these errors were encountered: