rich7420 opened a new pull request, #11169:
URL: https://github.com/apache/ozone/pull/11169
## What changes were proposed in this pull request?
`RDBTable.getRangeKVs` decided whether `startKey` exists with `get(startKey)
== null`,
a full point-get that materializes and then discards the value `byte[]`,
immediately
before `it.seek(startKey)` lands the iterator on that same key.
`seek()` already positions the iterator and returns the landing entry
without consuming
it (the range loop below still starts from that entry), so the existence
check can reuse
the landing entry instead of a separate get: `startKey` is present iff the
landing key
equals `startKey`.
Before:
```java
if ((prefix == null || startKey.length > prefix.length)
&& get(startKey) == null) {
// Key not found, return empty list
return result;
}
it.seek(startKey);
```
After:
```java
final KeyValue<byte[], byte[]> seeked = it.seek(startKey);
if ((prefix == null || startKey.length > prefix.length)
&& (seeked == null || !Arrays.equals(seeked.getKey(), startKey))) {
// start key not found, return empty list
return result;
}
```
This drops one point-get per `getRangeKVs` call plus the value `byte[]` it
allocated only
to discard. Behavior is unchanged: the loop still starts at the `seek()`
landing entry, and
the empty-result path fires on exactly the same inputs.
A JMH microbenchmark over a real RocksDB (100k keys, 512-byte values,
present start key),
old (extra get) vs new (seek landing check), average time and allocation per
call:
| page | time old -> new | alloc old -> new |
|---|---|---|
| 1 | 1.62 -> 0.99 us | 1136 -> 640 B/op |
| 10 | 3.86 -> 3.39 us | 6176 -> 5680 B/op |
| 100 | 27.6 -> 25.6 us | 56576 -> 56080 B/op |
| 1000 | 254 -> 250 us | 560581 -> 560085 B/op |
The saving is exactly one point-get: a constant ~496 B/op and ~0.5-0.6 us
per call, so it is
largest as a fraction on small pages (~39% at page 1) and shrinks toward the
iteration cost
as pages grow.
## What is the link to the Apache Jira
https://issues.apache.org/jira/browse/HDDS-16350
## How was this patch tested?
`TestRDBTableStore` (22 tests, 0 failures), including a new
`testRangeKVsStartKeyInclusiveAndAbsent` that pins the start-key contract:
present start key
returns a range starting inclusively at it, absent-in-the-middle and
absent-past-the-end keys
return empty (the past-end case exercises the `seek() == null` branch), and
the same holds with
`prefix == null`. The existing `testPrefixedRangeKVs` stays as a regression
guard. `checkstyle`
and `pmd` clean.
--
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]
