Conversation
The `options_snapshot` function was using up to 19% CPU in small incremental runs in a very large codebase, when not using orjson. Micro-optimize it, and use binary serialization instead of json. We can still make this faster, but first let's see how much this helps.
ilevkivskyi
left a comment
ilevkivskyi
left a comment
There was a problem hiding this comment.
OK, let's see if this will help.
| return result | ||
| # Process most options quickly, since this is performance critical. | ||
| buf = WriteBuffer() | ||
| write_json_value(buf, cast(JsonValue, values)) |
There was a problem hiding this comment.
This is somewhat surprising. When I measured it a while ago write_json_value() gave only marginal win compared to json_dumps() when using orjson (i.e. [faster-cache] option from pyproject.toml).
There was a problem hiding this comment.
Yeah it's only marginally faster than orjson based on microbenchmarking, but a lot faster compared to json. Since orjson is an optional dependency, I think it makes sense to prefer write_json_value (and it's still slightly faster than orjson probably).
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
|
Based on a CPU profile, this made the calculation reasonably faster compared to using stdlib |
2 participants
The
options_snapshotfunction was using up to 19% CPU in small incremental runs in a very large codebase, when not using orjson. Micro-optimize it, and use binary serialization instead of json.We can still make this faster, but first let's see how much this helps.