danny0405 commented on code in PR #19021:
URL: https://github.com/apache/hudi/pull/19021#discussion_r3870039596
##########
hudi-io/src/main/java/org/apache/hudi/io/hfile/HFileDataBlock.java:
##########
@@ -96,39 +99,57 @@ static HFileDataBlock createDataBlockToWrite(HFileContext
context,
int seekTo(HFileCursor cursor, Key key, int blockStartOffsetInFile) {
int relativeOffset = cursor.getOffset() - blockStartOffsetInFile;
int lastRelativeOffset = relativeOffset;
+ // The key-value cached at the starting position, if any. It is only
consulted to re-cache it
+ // in the cursor when the lookup lands "in range" on the very first
comparison; entries scanned
+ // past are compared directly against the backing buffer below (no
per-entry KeyValue/Key
+ // allocation), so this is emptied after the first iteration and the
cursor falls back to a
+ // deferred read.
Option<KeyValue> lastKeyValue = cursor.getKeyValue();
+ // The lookup key content is fixed across the scan; hoist it out of the
loop. Note the lookup
+ // key may be a UTF8StringKey, so use the polymorphic content accessors
(no 2-byte prefix).
+ byte[] lookupBytes = key.getBytes();
+ int lookupContentOffset = key.getContentOffset();
+ int lookupContentLength = key.getContentLength();
Review Comment:
[P2] Could the focused test also exercise a lookup `Key` whose content lives
at a non-zero offset in its backing array? The public reader API accepts the
base `Key`, and this optimization now bypasses `Key.compareTo` and manually
combines `getBytes()`, `getContentOffset()`, and `getContentLength()`. All new
lookups are created as `UTF8StringKey`, whose content offset is always zero, so
an offset regression in this direct-buffer path would still pass. A serialized
`Key` view (ideally over a larger buffer) targeting one of the mid-block
entries would lock down equivalence for both key representations.
--
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]
