Pool temporary buffers in the resolution linearization path - #998
Open
dersam wants to merge 1 commit into
Open
Conversation
dersam
marked this pull request as draft
August 10, 2026 19:26
dersam
force-pushed
the
buffer-pooling-allocation-reuse
branch
from
August 11, 2026 15:40
40106c9 to
b6c349a
Compare
Extract the buffer pooling / allocation reuse optimization from PR #983 into a standalone branch. The linearization recurses in strict last-in-first-out order, thus a plain list of spare buffers on the Resolver is enough. Changes (resolution.rs only): - Add chain_pool, mixin_pool, deque_pool, and spare_context to Resolver - Add take/return methods for each pool - Add LinearizationContext::reset for context reuse - ancestors_of reuses a spare LinearizationContext instead of allocating - linearize_ancestors builds the parent chain, mixin list, and result chain in pooled buffers; changed chains go into exact-size Vecs so the graph never holds spare capacity - linearize_parent_ancestors -> linearize_parent_ancestors_into writes into a caller-supplied buffer instead of returning an owned Vec - linearize_superclass -> linearize_superclass_into does the same - linearize_mixins takes &[Mixin] and Option<&[Ancestor]> and writes into caller-supplied VecDeques instead of allocating its own No behavior change: the graph is identical. All 1149 Rust tests pass, clippy is clean, and cargo fmt --check is clean.
dersam
force-pushed
the
buffer-pooling-allocation-reuse
branch
from
August 11, 2026 15:47
b6c349a to
c89869e
Compare
dersam
marked this pull request as ready for review
August 11, 2026 17:12
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
Resolvernow pools temporary buffers used during ancestor linearization, instead of allocating new ones for each linearization. Three internal functions were refactored from returning owned collections to writing into caller-provided buffers:linearize_parent_ancestors→linearize_parent_ancestors_intolinearize_superclass→linearize_superclass_intolinearize_mixins(signature change: takes&[Mixin]and&mut VecDequeinstead of owning and returning)Four pools were added to
Resolver:chain_pool: Vec<Vec<Ancestor>>— parent ancestor chain buffers (one per recursion level)mixin_pool: Vec<Vec<Mixin>>— collected mixin buffersdeque_pool: Vec<VecDeque<Ancestor>>— linearized prepend/include dequesspare_context: Option<LinearizationContext>— reused linearization context (hash sets retain capacity)The final
ancestorsVec is also pre-allocated with exact capacity (Vec::with_capacity(final_len)) to eliminate reallocations during assembly.Benchmark Results
Shopify core
Release mode, Apple M3 Pro. 111,463 Ruby files, ~1.14M declarations. Each binary ran 20 times sequentially with no concurrent heavy processes. Welch t-test for significance.
Raw per-run data (20 runs each)
Main (462de8e):
Branch (c89869e):