charlesconnell opened a new pull request, #6902: URL: https://github.com/apache/hbase/pull/6902
I've looked at a lot of allocation profiles of RegionServers doing a read-heavy workload. Some allocations that dominate the chart can be easily avoided. The following code in the main decode method ``` currentBuffer.asSubByteBuffer(currentBuffer.position(), current.keyLength, tmpPair); ByteBuffer key = tmpPair.getFirst().duplicate(); key.position(tmpPair.getSecond()).limit(tmpPair.getSecond() + current.keyLength); current.keyBuffer = key; ``` results in a new ByteBuffer for every cell. The reason to have this duplicate ByteBuffer is to hold the result of tmpPair.getSecond() as its position state. But this in just an integer that can be more cheaply stored in a different way. We can introduce a current.keyOffset variable and do this instead: ``` currentBuffer.asSubByteBuffer(currentBuffer.position(), current.keyLength, tmpPair); current.keyBuffer = tmpPair.getFirst(); current.keyOffset = tmpPair.getSecond(); ``` and then reference current.keyOffset where we previously referenced current.keyBuffer.position(). Additionally, `RowIndexSeekerV1.SeekerState` contains a `ByteBufferKeyOnlyKeyValue` field that is replaced on every cell read. This object can be reset and re-used instead. -- 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]
