Drop excess capacity from Suites during parsing#25368
Conversation
Merging this PR will improve performance by 5.67%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | Memory | ty_check_file[cold] |
21.7 MB | 20.8 MB | +4.32% |
| ⚡ | Memory | DateType |
25.4 MB | 24.3 MB | +4.78% |
| ⚡ | Memory | ty_micro[many_string_assignments] |
16.2 MB | 15.5 MB | +4.77% |
| ⚡ | Memory | ty_micro[pandas_tdd] |
44.2 MB | 42 MB | +5.29% |
| ⚡ | Memory | ty_micro[very_large_tuple] |
14.9 MB | 14.1 MB | +5.12% |
| ⚡ | Memory | ty_micro[large_isinstance_narrowing] |
16.2 MB | 15.4 MB | +4.88% |
| ⚡ | Memory | ty_micro[many_enum_members] |
17.5 MB | 16.7 MB | +4.36% |
| ⚡ | Memory | ty_micro[literal_match_fallthrough] |
13.5 MB | 12.8 MB | +4.94% |
| ⚡ | Memory | ty_micro[vararg_parameter_type_accumulation] |
13.1 MB | 12.5 MB | +5% |
| ⚡ | Memory | ty_micro[many_tuple_assignments] |
14.3 MB | 13.6 MB | +4.59% |
| ⚡ | Memory | ty_micro[complex_constrained_attributes_2] |
15.1 MB | 14.4 MB | +5.05% |
| ⚡ | Memory | ty_micro[literal_equality_fallthrough_guarded_any] |
15.7 MB | 15.1 MB | +4.21% |
| ⚡ | Memory | ty_micro[gradual_vararg_call] |
14.7 MB | 13.9 MB | +5.19% |
| ⚡ | Memory | ty_micro[complex_constrained_attributes_3] |
16.6 MB | 15.9 MB | +4.63% |
| ⚡ | Memory | ty_micro[complex_constrained_attributes_1] |
15.1 MB | 14.4 MB | +5.05% |
| ⚡ | Memory | ty_micro[many_enum_members_2] |
16.3 MB | 15.5 MB | +4.79% |
| ⚡ | Memory | ty_micro[many_protocol_members_mismatch] |
21.1 MB | 20.3 MB | +4.21% |
| ⚡ | Memory | ty_micro[many_tuple_assignments] |
15.6 MB | 14.9 MB | +4.87% |
| ⚡ | Memory | parser[pydantic/types.py] |
403.2 KB | 368.5 KB | +9.41% |
| ⚡ | Memory | parser[large/dataset.py] |
862.2 KB | 816.8 KB | +5.56% |
| ... | ... | ... | ... | ... | ... |
ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing micha/parser-shrink-to-fit (3ade505) with main (572e4b5)
|
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 91.94%. The percentage of expected errors that received a diagnostic held steady at 87.09%. The number of fully passing files held steady at 92/134. |
Memory usage reportSummary
Significant changesClick to expand detailed breakdownflake8
trio
sphinx
prefect
|
|
605800b to
974d9d7
Compare
dhruvmanila
left a comment
There was a problem hiding this comment.
I'm supportive of this. Related to the linter regression, possible alternatives could be to introduce a ty-specific API in the parser crate or have a new field in the ParseOptions but I'm not a fan of either options given that they'll be part of the public API.
|
IMO the memory gains here are clearly worth a 1-2% linter regression. |
cd1b259 to
67a08d4
Compare
bb45a9d to
60d29d6
Compare
|
I scoped this PR down to only cover statements to get a better sense for the performance trade-off when adding the same treatment to some other nodes. I also tried a few different techniques to mitigate the performance regression with very limited success:
In short, Vec is pretty fast |
Summary
Shrink Suite vectors to drop the excess capacity during parsing.
I excluded other nodes for now to get a better sense of the performance and memory impact.
I'm a bit conflicted on this. This is a pretty huge memory improvement for ty, but there are a few linter benchmarks that regress by 1-2% because some vectors need to be copied to smaller allocations, which hurts performance. For the linter and formatter, it's also not important to shrink the vectors, because the AST is never stored for long. But this is different for ty where we cache the AST.
I'm curious to hear what others think on this. I could also try to reduce the places where we call
shrink_to_fit, e.g., only for statements?