interactive: pin corgi at master; ids() borrows via leaf_slice - #814
Merged
frankmcsherry merged 3 commits intoJul 31, 2026
Merged
Conversation
ids() had its own copy of 'is this a u64 leaf' (bare Prim, or a 1-field Prod of one) duplicating what corgi can answer, and reached it via clone().into_u64() — the clone bumps the Arc, so into_u64's try-unwrap always fails and copies regardless, even for a freshly-gathered column with a single holder. leaf_slice answers the shape question once, in the layer that owns shapes, and hands back a borrow. 10 lines to 5, one shape-test instead of two. NOTE measured flat (scc 100 rounds: 51.05s vs 50.87s) — the copies removed were real but small; this is a simplification, not a performance change. Requires a corgi pin bump. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DDIR pinned 1301b281, a revision that existed on no branch — it lived only on the side line where corgi's arrange API was developed. That API is now on corgi's master (wip#9), and the read-path fixes on top of it (wip#8), so the pin can name master. The bump also delivers find_ranges' native u64 path, measured end-to-end here: scc, 100 rounds x batch 100: 63.66s -> 51.19s (-20%) reach, 1000 rounds x batch 100: 2.09s -> 1.56s (-25%) scc load-shaped @100k: 3.53s -> 3.50s (unchanged) Gate green, debug and release. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
frankmcsherry
force-pushed
the
arch-corgi-pin-bump
branch
2 times, most recently
from
July 31, 2026 21:10
36d7706 to
9c7c9eb
Compare
The comment said single-window presentation was 'a later refinement', which invites an experiment that does not pay. Measured: WINDOW = 1<<14 costs 33% time (scc, 100 rounds x batch 100: 84.4s vs 63.7s) and returns 4.4% memory (356MB -> 340MB peak RSS). The seek path removed windowing's asymptotic barrier but not its constant — per-window, per-chunk seek setup multiplies by the window count — and the presentation was never the memory peak; the trace is. Doc only; replaces an inviting TODO with the measurement. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
frankmcsherry
force-pushed
the
arch-corgi-pin-bump
branch
from
July 31, 2026 21:11
9c7c9eb to
b4cfd29
Compare
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.
Two commits: point the corgi dependency at master, then take the simplification that becomes available once it is there.
1. Bump the pin to corgi master (
c4626fc)DDIR pinned
1301b281— a revision that existed on no branch. It lived only on the side line where corgi'sarrangeAPI was developed, which made "what is DDIR actually building against?" surprisingly hard to answer (it cost me two wrong guesses while preparing the corgi PRs). That API is now on corgi's master (frankmcsherry/WIP#9), together with the read-path fixes on top of it (frankmcsherry/WIP#8), so the pin can simply name master.The bump also delivers
find_ranges' nativeu64path. Measured end-to-end here, same machine, back-to-back:The gains are in steady-state incremental work, where the reduce presentation probes the trace; load-dominated runs are unaffected, as expected.
2.
ids()borrows the leaf viacorgi::leaf_sliceids()carried its own copy of "is this au64leaf" — a barePrim, or a 1-fieldProdof one — duplicating a shape question corgi can answer, and reached it viaclone().into_u64(). That clone bumps theArc, sointo_u64's try-unwrap always fails and copies regardless, even for a freshly gathered column with a single holder.10 lines to 5, one shape test instead of two, and the shape question now lives in the layer that owns shapes.
Measured flat (scc 100 rounds: 51.05s vs 50.87s across the change) — the copies removed were real but small. This is a simplification, not a performance change; the numbers above come entirely from the pin bump.
Gate green in debug and release (12 programs).
🤖 Generated with Claude Code