hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Rodionov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9751) Excessive readpoints checks in MemStoreScanner and StoreFileScanner
Date Sat, 12 Oct 2013 19:05:42 GMT

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

Vladimir Rodionov commented on HBASE-9751:

Sorry that was optimized version:

Correct numbers: 71M and 80M respectively.

The additional optimization I have done to get up to 97.5M :

I replaced Bytes.compareTo with Bytes.equalsTo when checking for stopRow.  Its a dirty hack
but we always can calculate the *real* stopRow in a scanner, correct? If Scan operation has
isolation level READ_COMMITTED we calculate *real* stopRow when scanner is created. Checking
equality is much efficient than compare operation.

I am going to open separate JIRA for this possible improvement. 

> Excessive  readpoints checks in MemStoreScanner and StoreFileScanner
> --------------------------------------------------------------------
>                 Key: HBASE-9751
>                 URL: https://issues.apache.org/jira/browse/HBASE-9751
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.0, 0.94.12, 0.96.0
>            Reporter: Vladimir Rodionov
>            Assignee: Lars Hofhansl
>         Attachments: 9751-0.94.txt, 9751-trunk.txt
> It seems that usage of skipKVsNewerThanReadpoint in StoreFileScanner can be greatly reduced
or even eliminated all together (HFiles are immutable and no new KVs can be inserted after
scanner instance is created). The same is true for MemStoreScanner which checks readpoint
on every next() and seek(). Each readpoint check is ThreadLocal.get() and it is quite expensive.

This message was sent by Atlassian JIRA

View raw message