[
https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14551120#comment-14551120
]
Lars Hofhansl commented on HBASE-13448:
---------------------------------------
I'll also get some numbers. Not trying to be an ass here, BTW. :)
Cell's deciding what to cache, avoiding carry-over, etc, I get it. How far do
we get by just caching row length (not key-length)?
I also looked back at HBASE-7279, there I removed the row cache (where we copy
and cache the row key as well as the timestamp cache). Those didn't help in the
sampler sessions I did. Saying that: Caching row-length and key-length is
different, and does not necessarily go against what I wanted to achieve in
HBASE-7279.
It's just that I've seen more issues with GC than wasted CPU.
If we can back it up by numbers, let's do it. The row length cache seems fine
(just 2 bytes, and called often), I'm more dubious about the key length cache.
> 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)
