[jira] [Commented] (HBASE-9751) Excessive readpoints checks in MemStoreScanner and StoreFileScanner

["Vladimir Rodionov (JIRA)" <ji...@apache.org>]

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

Vladimir Rodionov commented on HBASE-9751:
------------------------------------------

The possible optimization won't give much performance improvement unless tested directly on MemStoreScanner. There are many others performance issues on a scanner read path which will obscure the performance gain. The major offenders: 

* new instance of KeyValue on every StoreScanner.next() (regardless of Filter selectivity).
* sub-par implementation of :

        ScanQueryMatcher.MatchCode qcode = matcher.match(kv); in StoreScanner.next()

ScanQueryMatcher code is responsible for > 50% of execution time of of StoreScanner.next(). 

Object creation in Java becomes expensive in MT mode.

> 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
>
> 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
(v6.1#6144)