lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Paldino (JIRA)" <>
Subject [jira] Updated: (LUCENENET-292) Optimization of EquatableList<T>
Date Fri, 20 Nov 2009 16:36:40 GMT


Nicholas Paldino updated LUCENENET-292:

    Attachment: SupportClass.patch

Some points:

- The AddRange issue (specifically, the setting of the Capacity property) was correctly addressed
in the second optimization patch, you were working off the first, which I had removed, corrected,
and then added back.

- Your implementation of Clone was excessive.  The constructor for EquitableList<T>
takes a parameter of IEnumerable<T> (which EquitableList<T> implements) and then
passes itself to the constructor of the new instance.  See the documentation at:

Specifically the part that says:

If the size of the collection can be estimated, specifying the initial capacity eliminates
the need to perform a number of resizing operations while adding elements to the List<(Of

Since EquitableList<T> derives from List<T> and that constructor that takes IEnumerable<T>
calls the same base class constructor, it has the same properties.  Since EquitableList<T>
implements ICollection<T>, which provides a way to estimate the size of the collection,
it will use that mechanism.

- I've only commented out the operators and left a TODO.  Best practices dictate that when
overloading Equals, you overload == (and subsequently !=).  These should be implemented and
then used later when the project takes a turn to follow best .NET practices, and it's easier
to just uncomment code then type it over again. =)

> Optimization of EquatableList<T>
> --------------------------------
>                 Key: LUCENENET-292
>                 URL:
>             Project: Lucene.Net
>          Issue Type: Improvement
>            Reporter: Nicholas Paldino
>            Priority: Minor
>         Attachments: EquatableList2.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