lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Paldino (JIRA)" <>
Subject [jira] Commented: (LUCENENET-292) Optimization of EquatableList<T>
Date Sat, 21 Nov 2009 17:14:39 GMT


Nicholas Paldino commented on LUCENENET-292:

It is necessary as it addresses a bug in EquitableList<T> concerning the AddRange method
and correctly setting the Capacity.

It also implements the IClonable interface, which is needed in other places where EquitableList<T>
would be used in place for ArrayList to keep the Java and .NET more closely synchronized.

The optimization is what originally drove the issue, but caused these other things to be addressed.

And given that Lucene .NET shares the performance concerns of Lucene, and an optimization
like this would definitely have an impact in places where it is used (where sequences have
to be compared), one could argue it's necessary, especially if the lists being compared are
both large and do not have the same number of items.

In summary, I think that points #1 and #2 make it necessary without question, while #3 is
a more subjective decision, but still a strong argument for inclusion none the less (Michael
indicated his favor for such when this optimization was mentioned in LUCENENET 284).

> Optimization of EquatableList<T>
> --------------------------------
>                 Key: LUCENENET-292
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Improvement
>            Reporter: Nicholas Paldino
>            Priority: Minor
>         Attachments: EquatableList3.patch, SupportClass.patch
> When comparing two IEnumerable<T> implementations, a shortcut can be taken to check
to see if both IEnumerable<T> expose operations which returns a count of items (sequences
cannot be equal if the number of elements in the sequences are not equal).
> Typically, in .NET, this is expressed through the implementation of the ICollection or
ICollection<T> interface.
> Before enumerating through each element and comparing the two for equality, if the counts
are accessible, they should be compared to see if the number of elements in the two sequences
are equal.  If a comparison is able to be made before enumerating, it will be much more performant
for comparisons of sequences where each is ~N, but both are not equal to N, and N is very
> Patch to follow.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message