Oh, hm I completely forgot 32-bit architectures are still a thing. Probably an easy fix, not sure I will have time to take a look at it today, but it should not stop any reviewers from reviewing.

(Not a full review.)

Nice, this is a major improvement! I measured a ~35% performance improvement in import torch when cached, compared to using the old cache format. Once deserialization is faster, we can hopefully further improve warm runtimes by improving the performance of remaining bottlenecks.

I did a quick review, and this seems good enough to merge (or at least close enough). Let's leave this open for another day in case somebody still wants to have a look. Before making this an official feature, there are some changes that I think would be nice to have (beyond a way of distributing this), but these are better done as follow-up PRs and I won't discuss them here. I also have some smaller comments that are easier for me to address in a follow-up PR than writing detailed review comments here.

I also want to remove the JSON based format eventually, maybe a few releases after we've made this the default. This may require a way of converting the binary cache to JSON, since at least at Dropbox we have some tools that process mypy cache files, and processing a binary format in tools sounds pretty painful. I have some ideas about how to achieve this without making the serialization code significantly harder to maintain or less efficient. I'll write about this in a follow-up issue.

Added link to related issue #3456 in summary.

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@JukkaL

Added link to related issue #3456 in summary.

Oh, I completely forgot about that issue, and I see you even posted a proposal there. It is interesting that I wrote something very similar to what you propose, few comments:

• I actually had write_short_int() and read_short_int() for type/symbol tags (one byte per tag) at some point. I didn't include them in the PR because it had only minor effect on performance. But they will definitely allow to cut a big chunk of cache size (IIRC they reduced cache size by at least 20% in my experiments).
• As you mentioned, attribute name tags are technically redundant, and actually debugging was not that hard without them, so I think we don't really need them.
• I think we can add few dedicated tags for most common instances like builtins.str and return same object for them (essentially what we do in type-checker with named_type()).

Before making this an official feature, there are some changes that I think would be nice to have (beyond a way of distributing this), but these are better done as follow-up PRs and I won't discuss them here. I also have some smaller comments that are easier for me to address in a follow-up PR than writing detailed review comments here.

OK, yeah, this will definitely speed things up.