hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13448) New Cell implementation with cached component offsets/lengths
Date Tue, 19 May 2015 16:36:03 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14550736#comment-14550736

stack commented on HBASE-13448:

bq. What about key length? 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).

We ARE getting rid of the notion of key length being scattered around the code base. In its
place, Cell implementations figure what needs to be cached. Whatever caching is done is encapsulated
by the Cell implementation.

No harm gating this on new numbers. Let me try and get to it (Any luck w/ a Region-based jmh
implementation [~anoop.hbase] / [~ram_krish] ?)

Again, to be clear:

+ This patch brings minor throughput improvement at the cost of some more GC
+ This patch simplifies code path removing a bunch of housekeeping 'carrying-over' calculated
lengths done in various locations such as SQM and elsewhere where we do Cell compares.

> 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,
> This can be extension to KeyValue and can be instantiated and used in read path.

This message was sent by Atlassian JIRA

View raw message