[
https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549869#comment-14549869
]
ramkrishna.s.vasudevan commented on HBASE-13448:
------------------------------------------------
bq.Not all Cells will have a notion of a key length, I thought we're going to
get rid of it (rather than now cementing its use more by caching the key
length).
I would say 'yes', we are getting rid of it even now. But KeyValue, a type of
Cell works based on keylength and where ever KeyValue is used in read side its
better to cache it (the perf reading part wrt GC need to say though). Overall
the read path is actually not bothered about how the key or the key length is
getting used. Previously the read path was directly using the key or keylength
and trying to infer the details about a Cell.
As Stack said a Cell would know what to be cached. If you take any cell coming
from the encoders we don't do this.
> 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)
