Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 6 Aug 2015 16:52:06 +0000 (UTC)
From: "Ted Yu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12851440.1438709952000.391100.1438879926020@Atlassian.JIRA>
In-Reply-To: <JIRA.12851440.1438709952000@Atlassian.JIRA>
References: <JIRA.12851440.1438709952000@Atlassian.JIRA>
 <JIRA.12851440.1438709952604@arcas>
Subject: [jira] [Commented] (HBASE-14186) Read mvcc vlong optimization
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ted Yu commented on HBASE-14186:
--------------------------------

+1 on integrating to branch-1

> Read mvcc vlong optimization
> ----------------------------
>
>                 Key: HBASE-14186
>                 URL: https://issues.apache.org/jira/browse/HBASE-14186
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance, Scanners
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0
>
>         Attachments: HBASE-14186.patch
>
>
> {code}
> for (int idx = 0; idx < remaining; idx++) {
>   byte b = blockBuffer.getByteAfterPosition(offsetFromPos + idx);
>   i = i << 8;
>   i = i | (b & 0xFF);
> }
> {code}
> Doing the read as in case of BIG_ENDIAN.
> After HBASE-12600, we tend to keep the mvcc and so byte by byte read looks eating up lot of CPU time. (In my test HFileReaderImpl#_readMvccVersion comes on top in terms of hot methods). We can optimize here by reading 4 or 2 bytes in one shot when the length of the vlong is more than 4 bytes. We will in turn use UnsafeAccess methods which handles ENDIAN.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)