jbewing commented on code in PR #5576:
URL: https://github.com/apache/hbase/pull/5576#discussion_r1433097154
##########
hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValueUtil.java:
##########
@@ -226,7 +226,7 @@ public static KeyValue nextShallowCopy(final ByteBuffer bb,
final boolean includ
int kvLength = (int) KeyValue.getKeyValueDataStructureSize(keyLength,
valueLength, tagsLength);
KeyValue keyValue = new KeyValue(bb.array(), underlyingArrayOffset,
kvLength);
if (includesMvccVersion) {
- long mvccVersion = ByteBufferUtils.readVLong(bb);
+ long mvccVersion = ByteBufferUtils.readVLongTimestamp(bb);
Review Comment:
I'm not sure what approach is better between
[HBASE-14186](https://issues.apache.org/jira/browse/HBASE-14186) and this
approach. This approach has the benefit of in the average case (where the
remaining size of the buffer contains 8 bytes) doing less operations on the
underlying ByteBuff after checking the size byte regardless of the size of the
vLong (3 ops). The ByteBuff operations are typically slow in flamegraphs not
because the actual methods are expensive to evaluate, but because
`checkRefCount()` is typically quite expensive.
I can do some microbenchmarks comparing the current approach,
[HBASE-14186](https://issues.apache.org/jira/browse/HBASE-14186)-like approach,
and the approach taken in this patch against each other for vLongs of all sizes.
--
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]
