[
https://issues.apache.org/jira/browse/HBASE-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570678#comment-13570678
]
Lars Hofhansl commented on HBASE-7755:
--------------------------------------
I was thinking about this too.
On the other hand the decoding is a function of scanning through the blocks,
and it seems the LAB should be independent from the caching of the block
(maybe).
I think ideally a scanner would own the LAB, but it does not know the block
size ahead of time.
Another option is having the HFile itself owning the LAB for all block access
through it.
I had almost convinced myself that BufferedEncodedSeeker *is* right place.
So the options are:
* block cache
* an HFileReader
* a Scanner
* more?
> Experiment with LAB in BlockEndcoding
> -------------------------------------
>
> Key: HBASE-7755
> URL: https://issues.apache.org/jira/browse/HBASE-7755
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Fix For: 0.94.6
>
> Attachments: 7755-0.94-W_I_P_v1.txt, 7755-0.94-WORK_IN_PROGRESS.txt
>
>
> I was looking at and profiling the BlockEncoding code to figure out how to
> make it faster. One issue that jumped out was we call
> ByteBuffer.allocate(...) for each single KV.
> As an experiment I tried using the MemStoreLAB code to allocate those buffers.
> Here are some preliminary numbers, all scanning 10m rows (all in cache):
> * no encoding: 5.2s
> * FAST_DIFF without patch: 7.3s
> * FAST_DIFF with patch and small LAB: 4.1s
> * FAST_DIFF with patch and large LAB: 11s
> So this is very sensitive to the right sizing of the LAB.
> Need to do a bit more testing, but it seems that there is a chance to
> actually make scanning with block encoding faster than without!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
