Merging this PR will improve performance by 22.35%

⚡ 91 improved benchmarks
❌ 12 regressed benchmarks
✅ 1478 untouched benchmarks

Performance Changes

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

_{Comparing ngates/session-parent-kernels (b7a1dd9) with develop (aef6307)}

@claude review it

Claude finished @gatesn's task in 8m 1s —— View job

PR Review: Move execute-parent kernels into session registry

I traced the refactor end-to-end: the removed VTable::execute_parent / DynArrayData::execute_parent, the new register_execute_parent_kernel + DynExecuteParentKernel registry, the executor dispatch, the ArraySession/ArrayKernels wiring, and per-encoding migrations. Overall this is a clean, well-executed unification and the mechanism is sound. A few findings below, none blocking.

Findings

1. Stale developer docs reference the removed ParentKernelSet (docs) — should fix in this PR

docs/developer-guide/internals/execution.md:118 still says:

An encoding declares its parent kernels in a ParentKernelSet, specifying which parent types each kernel handles via a Matcher

ParentKernelSet is fully deleted (no Rust references remain). Encodings now register with session.kernels().register_execute_parent_kernel(parent_id, Child, Kernel). The doc example is also out of date: it shows array: &V::Array, but the trait (vortex-array/src/kernel.rs:41) now takes array: ArrayView<'_, V>. Since this is the canonical "how to add a parent kernel" reference, it's now actively misleading. Fix this →

2. Lost unconditional debug invariant on execute_parent results (low, debug-only)

The deleted DynArrayData::execute_parent had an unconditional debug_assertions guard:

vortex_ensure!(result.len() == parent.len(), "Executed parent canonical length mismatch");
vortex_ensure!(result.dtype() == parent.dtype(), "Executed parent canonical dtype mismatch");

The new dispatch (executor.rs:561 execute_parent_for_child) returns the kernel result directly with no such check. The doc comments on both ExecuteParentFn (optimizer/kernels.rs:89) and the kernel doc still assert "Implementations must preserve the parent's logical length and dtype" — but nothing enforces it at the rewrite site anymore. Downstream pop_frame (executor.rs:514) and finalize_done (executor.rs:542) give partial coverage when a grandparent frame exists, but not for a root parent or all Step-2b (own-child) rewrites. A buggy kernel that returns the wrong length/dtype would now slip past the point it used to be caught. Cheap to restore: re-add the cfg!(debug_assertions) check inside execute_parent_for_child after a kernel returns Some. Fix this →

3. Precedence change for execute-parent overrides (behavioral note, low impact)

Previously the executor tried session-registered execute_parent plugins before the encoding's static PARENT_KERNELS, so a later registration could take precedence over a built-in. Now built-in kernels are themselves registered (at ArraySession::default / encoding initialize time) and additional registrations are appended (register_execute_parent_kernel → ArcSwapMap::push → extend), so they are tried after built-ins for the same (parent, child) key. This matches the intentional edit to the module doc (which dropped "or kernel" from the precedence claim for execute), so it appears deliberate — but extension authors who relied on overriding a built-in fused execution path can no longer do so by registration order. Worth a one-line note in the register_execute_parent_kernel rustdoc that it cannot override built-ins for an existing key.

Verified (no action needed)

• Migration completeness: every encoding that previously exposed execute_parent/PARENT_KERNELS now both registers via register_execute_parent_kernel and wires kernel::initialize from its crate initialize (checked alp, alp_rd, bytebool, datetime-parts, decimal-byte-parts, onpair, fastlanes {bitpacking, for, rle}, fsst, parquet-variant, runend, sequence, sparse, zigzag, plus all built-in arrays via arrays::initialize).
• Registry wiring is correct: ArraySession::default registers built-ins into this.kernels through a temp session holding this.kernels.clone(); ArcSwapMap::clone shares the same Arc<ArcSwap> cell (confirmed by arc_swap_map::clone_shares_the_same_cell and the new array_session_default_registers_builtin_kernels test), so registrations land in the stored registry rather than a throwaway copy.
• Keying is correct: dispatch uses (parent.encoding_id(), child.encoding_id()), reusing the pre-existing reduce-parent scheme. Scalar-fn arrays report their function id as encoding_id() (ScalarFnArrayPlugin::id → self.0.id()), so registrations under Cast.id()/Binary.id()/Filter.id()/etc. resolve as intended. The RegisteredExecuteParentKernel still re-checks K::Parent::try_match(parent), so a non-matching op (e.g. a non-comparison Binary) correctly falls through.
• Ordering preserved: per-key registration order matches the old ParentKernelSet arrays (e.g. RunEnd Dict: TakeExecuteAdaptor then RunEndTakeFrom; parquet-variant: Filter, Slice, Take, VariantGet).
• Snapshot timing: ExecutionCtx::new snapshots the execute-parent kernels once per ctx, which is safe because registration happens at session-build time.

Performance

The snapshot-per-ctx approach plus reduced dispatch overhead is reflected in CodSpeed's net +24.5%. The 7 flagged regressions (bitpacking take ~ -16–18%, encode_varbin -20%) are on the Walltime/hosted-runner instrument that CodSpeed itself warns is inconsistent — worth a glance but likely measurement noise rather than a real cost of this change.

Checks not run

This is a read-only review; I did not run cargo build/clippy/tests (CodSpeed confirms the branch compiles and runs). The findings above are static-analysis based.
· ngates/session-parent-kernels