[ https://issues.apache.org/jira/browse/HBASE-10805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-10805: ---------------------------------- Attachment: 10805-trunk.txt Trunk patch to get a test run through, just to be sure. > Speed up KeyValueHeap.next() a bit > ---------------------------------- > > Key: HBASE-10805 > URL: https://issues.apache.org/jira/browse/HBASE-10805 > Project: HBase > Issue Type: Bug > Reporter: Lars Hofhansl > Fix For: 0.99.0, 0.94.19, 0.98.2, 0.96.3 > > Attachments: 10805-trunk.txt > > > See discussion on HBASE-9969. > This was brought up by [~mcorgan]. Even though I didn't believe him first. > {code} > KeyValueScanner topScanner = this.heap.peek(); > if (topScanner == null || > this.comparator.compare(kvNext, topScanner.peek()) >= 0) { > this.heap.add(this.current); > this.current = pollRealKV(); > } > {code} > We already have the invariant everywhere this.current always has a real KV > polled. So adding current back to the heap followed by pollRealKV() is a > no-op if this.current is the only scanner anyway. > This can be changed to: > {code} > ... > if (topScanner != null && > this.comparator.compare(kvNext, topScanner.peek()) >= 0) { > ... > {code} > With 20m rows, 5 cols each, everything in the cache, fully compacted - i.e. > one HFile per store, a scan that filters everything at the server through all > 100m KVs takes 15.1s without the change and 13.3s with it, so a 12% > improvement. -- This message was sent by Atlassian JIRA (v6.2#6252)