[
https://issues.apache.org/jira/browse/HBASE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869295#comment-13869295
]
Lars Hofhansl commented on HBASE-10320:
---------------------------------------
bq. Where should we see the improvement overall?
Scanning with ExplicitColumnTracker (i.e. a scan where some columns were added
with addColumn) and where all/most data is filtered out at the server (by a
filter or a coprocessor).
So in PE the FilteredScanTest might do it. If you run that, let me know what
you find. Might be that in all but extreme cases this is just in the noise. I
think PE has relatively large columns (1000 bytes), so it might not show.
Will wait with commit until we've had a PE test.
> 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.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)
