[ https://issues.apache.org/jira/browse/ACCUMULO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511430#comment-15511430 ]
Josh Elser edited comment on ACCUMULO-4468 at 9/21/16 10:44 PM: ---------------------------------------------------------------- --Looking at the repo, it's important that the code is not doing a {{previous.equals(next)}} but actually {{previous.equals(next, PartialKey.ROW_COLFAM)}}.-- Jk, I see you did mention this and I just didn't read closely. was (Author: elserj): Looking at the repo, it's important that the code is not doing a {{previous.equals(next)}} but actually {{previous.equals(next, PartialKey.ROW_COLFAM)}}. > accumulo.core.data.Key.equals(Key, PartialKey) improvement > ---------------------------------------------------------- > > Key: ACCUMULO-4468 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4468 > Project: Accumulo > Issue Type: Improvement > Components: core > Affects Versions: 1.8.0 > Reporter: Will Murnane > Priority: Trivial > Labels: newbie, performance > Attachments: benchmark.tar.gz, key_comparison.patch > > > In the Key.equals(Key, PartialKey) overload, the current method compares > starting at the beginning of the key, and works its way toward the end. This > functions correctly, of course, but one of the typical uses of this method is > to compare adjacent rows to break them into larger chunks. For example, > accumulo.core.iterators.Combiner repeatedly calls this method with subsequent > pairs of keys. > I have a patch which reverses the comparison order. That is, if the method is > called with ROW_COLFAM_COLQUAL_COLVIS, it will compare visibility, cq, cf, > and finally row. This (marginally) improves the speed of comparisons in the > relatively common case where only the last part is changing, with less > complex code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)