[jira] [Updated] (HBASE-7755) Experiment with LAB in BlockEndcoding

["Lars Hofhansl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Hofhansl updated HBASE-7755:
---------------------------------

    Attachment: 7755-0.94-WORK_IN_PROGRESS.txt

Here's a *work in progress* that attempts to derive a reasonable size of the LAB from the block size.
It's not configurable, yet, it may crash and burn your machine.
Also still experimenting with who should own the LAB. BufferedEncodedSeeker in the end is probably not the right place, since it is created to frequently.
                
> 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
>         Attachments: 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