[
https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549944#comment-14549944
]
Anoop Sam John commented on HBASE-13448:
----------------------------------------
Thanks Ram.. He explained it mostly.
Yes we are not adding keylength stufff back. This is only within a specific
Cell impl, ie. KeyValue where key length make sense. You can see above how
many times we call each of the methods in read of a cell. As per that it is
clear that keylength calc is happening more often, as this is needed by some
other offset/length.
Yes 2-3% gain only what I also saw in a small single node run. But Stack ran
the test on V1 patch where I tried to cache many other items. Per KeyValue
object we were adding some 24+ bytes extra cost. The latest version of patch
just adds 6 bytes extra. Yet to take a GC reading. Will do that. Any chance
of giving a try in ur cluster Stack?
As Stack explained, we are trying to get rid of caching the offset/length and
passing it around in the read path. We used to pass byte[] , offset, length .
This is part of the offheap read work where we better pass the Cell. As the
subtasks of that gets done, we will tend to call these getters more and caching
makes more sense then.
> New Cell implementation with cached component offsets/lengths
> -------------------------------------------------------------
>
> Key: HBASE-13448
> URL: https://issues.apache.org/jira/browse/HBASE-13448
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-13448.patch, HBASE-13448_V2.patch,
> HBASE-13448_V3.patch, gc.png, hits.png
>
>
> This can be extension to KeyValue and can be instantiated and used in read
> path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
