[
https://issues.apache.org/jira/browse/LUCENENET-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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:
http://msdn.microsoft.com/en-us/library/fkbw11z0.aspx
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 <(T>)>).
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: https://issues.apache.org/jira/browse/LUCENENET-292
> 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 large.
> Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
