Dandandan commented on code in PR #23162:
URL: https://github.com/apache/datafusion/pull/23162#discussion_r3472419142


##########
datafusion/physical-plan/src/sorts/cursor.rs:
##########
@@ -209,29 +243,85 @@ impl<T: ArrowPrimitiveType> CursorArray for 
PrimitiveArray<T> {
     type Values = PrimitiveValues<T::Native>;
 
     fn values(&self) -> Self::Values {
-        PrimitiveValues(self.values().clone())
+        PrimitiveValues::new(self.values().clone())
     }
 }
 
+/// [`CursorValues`] for a primitive column.
+///
+/// The value at the cursor's current offset — and the one immediately before 
it
+/// — are cached in [`Self::set_offset`] (called once per [`Cursor::advance`]).
+/// The hot loser-tree comparisons (`compare`/`eq_to_previous`), which always
+/// operate at the cursor's *current* position, then read these cached fields
+/// instead of indexing (and bounds-checking) the buffer on every comparison.
 #[derive(Debug)]
-pub struct PrimitiveValues<T: ArrowNativeTypeOp>(ScalarBuffer<T>);
+pub struct PrimitiveValues<T: ArrowNativeTypeOp> {
+    values: ScalarBuffer<T>,
+    /// Cached value at the current offset (`values[offset]`).
+    current: T,
+    /// Cached value at the previous offset (`values[offset - 1]`); meaningful
+    /// once the cursor has advanced past offset 0 (the only case in which
+    /// `eq_to_previous` reads it).
+    previous: T,
+    /// The current offset. Kept solely to `debug_assert!` that the cache is 
read
+    /// at the position the caller claims, guarding the invariant the cache
+    /// relies on; it is not used to index the buffer.
+    offset: usize,
+}
+
+impl<T: ArrowNativeTypeOp> PrimitiveValues<T> {
+    fn new(values: ScalarBuffer<T>) -> Self {
+        // Cursors are only built over non-empty batches; the 
`unwrap_or_default`
+        // merely avoids a panic for the (unreachable) empty case.
+        let first = values.first().copied().unwrap_or_default();
+        Self {
+            values,
+            current: first,
+            previous: first,
+            offset: 0,
+        }
+    }
+}
 
 impl<T: ArrowNativeTypeOp> CursorValues for PrimitiveValues<T> {
+    #[inline(always)]
     fn len(&self) -> usize {
-        self.0.len()
+        self.values.len()
     }
 
+    #[inline(always)]
     fn eq(l: &Self, l_idx: usize, r: &Self, r_idx: usize) -> bool {
-        l.0[l_idx].is_eq(r.0[r_idx])
+        // Arbitrary indices (used when comparing across batch boundaries), so
+        // this path indexes the buffer directly rather than using the cache.
+        l.values[l_idx].is_eq(r.values[r_idx])

Review Comment:
   Agreed, that `eq` (the cross-batch path) still indexes and could drop its 
bounds check with `unsafe`. I kept this PR `unsafe`-free intentionally, and the 
cache already removes the *per-comparison* checks on the hot loser-tree path 
(the once-per-row `set_offset` index is elided by the `offset < len` guard in 
`advance`). Happy to explore `unsafe` for the remaining `Vec`/`eq` indexing in 
a follow-on.



##########
datafusion/physical-plan/src/sorts/cursor.rs:
##########
@@ -180,10 +206,18 @@ impl RowValues {
 }
 
 impl CursorValues for RowValues {
+    #[inline]
     fn len(&self) -> usize {
         self.rows.num_rows()
     }
 
+    // NOTE: `eq`/`eq_to_previous`/`compare` are deliberately NOT `#[inline]`.

Review Comment:
   Good point — I tried that. `#[inline(never)]` actually regresses the 
multi-column path (~+12% on the `multiple_u64_columns` bench), as does 
`#[inline]`; leaving the decision to the compiler is fastest here. Reworded the 
comment to say that explicitly rather than imply a "no-inline" intent.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to