[
https://issues.apache.org/jira/browse/HBASE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870178#comment-13870178
]
Lars Hofhansl commented on HBASE-10320:
---------------------------------------
Thanks [~eclark]! Looking the code you tested the equivalent of the first patch.
I found later (after JM pointed it out) that ArrayList.size() added more load
across the cores did you see this too (and that precalculating the length was
better after all)?
Also any chance of trying the same with just arrays (i.e. what -v3 does)?
> Avoid ArrayList.iterator() in tight loops
> -----------------------------------------
>
> Key: HBASE-10320
> URL: https://issues.apache.org/jira/browse/HBASE-10320
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: Lars Hofhansl
> Attachments: 10320-0.94-v2.txt, 10320-0.94-v3.txt, 10320-0.94.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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
