[jira] [Resolved] (HBASE-10320) Avoid ArrayList.iterator() ExplicitColumnTracker

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

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

Lars Hofhansl resolved HBASE-10320.
-----------------------------------

      Resolution: Fixed
    Hadoop Flags: Reviewed

Committed to all branches. Thanks for the reviews, and especially to [~eclark] for the benchmarking.

> Avoid ArrayList.iterator() ExplicitColumnTracker
> ------------------------------------------------
>
>                 Key: HBASE-10320
>                 URL: https://issues.apache.org/jira/browse/HBASE-10320
>             Project: HBase
>          Issue Type: Bug
>          Components: Performance
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17
>
>         Attachments: 10320-0.94-v2.txt, 10320-0.94-v3.txt, 10320-0.94-v4.txt, 10320-0.94.txt, 10320-trunk-v4.txt
>
>
> I noticed that in a profiler (sampler) run ScanQueryMatcher.setRow(...) showed up at all.
> In turns out that the expensive part is iterating over the columns in ExcplicitColumnTracker.reset(). I did some microbenchmarks and found that
> {code}
> private ArrayList<X> l;
> ...
> for (int i=0; i<l.size(); i++) {
>    X = l.get(i);
>    ...
> }
> {code}
> Is twice as fast as:
> {code}
> private ArrayList<X> l;
> ...
> for (X : l) {
>    ...
> }
> {code}
> The indexed version asymptotically approaches the iterator version, but even at 1m entries it is still faster.
> In my tight loop scans this provides for a 5% performance improvement overall when the ExcplicitColumnTracker is used.
> Edit:
> {code}
> private X[] l;
> ...
> for (int i=0; i<l.length; i++) {
>    X = l[i];
>    ...
> }
> {code}
> Is even better. Apparently the JVM can even save the boundary check in each iteration.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)