Typing conformance results

No changes detected ✅

Memory usage report

Summary

Significant changes

ecosystem-analyzer results

No diagnostic changes detected ✅

Full report with detailed diff (timing results)

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

Merging this PR will improve performance by 6.88%

⚡ 5 improved benchmarks
✅ 118 untouched benchmarks

Performance Changes

_{Comparing micha/thin-vec-stmt (fecd00b) with main (0909c7e)}

For my own education: how do you decide whether to use ThinVec or a boxed slice for things like this?

I only used ThinVec in T when it helped to reduce the size of Sequence<T> or the size of an enum where T is a variant. E.g. Using a ThinVec for StmtClassDef helped reduce the size of Stmt. I didn't not change items in ExprDict, because ExprDict isn't the largest Expr variant and reducing its size is, therefore, not very meaningful.

I naively would've expected: ThinVec where we need mutability, boxed slice where the data is now immutable.

ThinVec is smaller than a boxed slice, because it moves the capacity and length into the heap allocation. This is also one of the main downsides. Reading the length now requires a pointer dereference

These are AST nodes, so I think the data is always immutable (and I would also have naively gone for boxed slices here as well, for the same reason!). But taking up less space on the stack is obviously a very good reason to go for ThinVec, given the big memory savings here. Nice optimisation! 😃

Oh yeah I didn't realize it was even smaller, nice.