showuon opened a new pull request #11181:
URL: https://github.com/apache/kafka/pull/11181
Currently in `upperRange` method, we'll check key bytes 1 by 1, to see if
there's a byte value >= first timestamp byte value, so that we can skip the
following key bytes, because we know `compareTo` will always return 0 or 1.
Take this test for example (in `WindowKeySchemaTest`)
```java
public void
testUpperBoundWithKeyBytesLargerAndSmallerThanFirstTimestampByte() {
// here, because the 3rd byte of the key (0x9) < the first timestamp
byte (0xA), we'll skip this type, and appending the timestamp directly
final Bytes upper = windowKeySchema.upperRange(Bytes.wrap(new byte[]
{0xC, 0xC, 0x9}), 0x0AffffffffffffffL);
// so the tested shorter key should be included in the upper range
assertThat(
"shorter key with timestamp should be in range",
upper.compareTo(
WindowKeySchema.toStoreKeyBinary(
new byte[] {0xC, 0xC},
0x0AffffffffffffffL,
Integer.MAX_VALUE
)
) >= 0
);
assertThat(upper, equalTo(WindowKeySchema.toStoreKeyBinary(new
byte[] {0xC, 0xC}, 0x0AffffffffffffffL, Integer.MAX_VALUE)));
}
```
Furthermore, since we don't know how many bytes are skipped, we did a
byteBuffer copy to another byte array.
However, in most cases, the first timestamp byte is actually **0**, because
even we use the current timestamp (i.e. `System.currentTimeMillis()`), the
first timestamp type will be `0`.
This PR optimizes the common first timestamp byte `0` case by not checking
the key byte 1 by 1, instead, put all bytes and timestamp directly.
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
