[
https://issues.apache.org/jira/browse/ACCUMULO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510541#comment-15510541
]
Josh Elser commented on ACCUMULO-4468:
--------------------------------------
Hi [~wmurnane]. Thanks for the patch.
bq. 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.
Do you have other examples of where this might be used in a tight loop?
bq. This (marginally) improves the speed of comparisons in the relatively
common case where only the last part is changing, with less complex code.
How did you test this? What types of numbers did you see?
{code}
+ case ROW:
+ if (!isEqual(row, other.row))
+ return false;
+ break;
default:
throw new IllegalArgumentException("Unrecognized partial key
specification " + part);
}
+ return true;
{code}
Why not consolidate this to:
{code}
case ROW:
return isEquals(row, other.row);
{code}
> 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: 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)
