You don't have to be worried about the performance. Please note, the SftpItemCollection behaves as an associative array (see the line collection2[item1.Name]), so searching time complexity is O(1) = Constant time (it works with a Dictionary internally).
If the performance has to be taken into consideration I suggest you one optimization of the second solution. The optimal approach of the Intersect problem on unsorted collection runs in O(n) = Linear time complexity. But in real life it matter whether the 'n' is 3 or 3000. The second algorithm iterates over the collection1, but the optimal solution is to iterate over the shortest one.
private SftpItemCollection Intersect(SftpItemCollection collection1, SftpItemCollection collection2)
{
bool swapCollections = collection1.Count > collection2.Count;
SftpItemCollection shorter, larger;
if (swapCollections)
{
shorter = collection2;
larger = collection1;
}
else
{
shorter = collection1;
larger = collection2;
}
SftpItemCollection result = new SftpItemCollection();
foreach (SftpItem item1 in shorter)
{
SftpItem item2 = larger[item1.Name];
if (item2 != null && item1.Size == item2.Size && item1.Modified == item2.Modified)
result.Add(swapCollections ? item2 : item1);
}
return result;
}
To make a picture about the Linq Intersect method time complexity, you can add informative printings into the SftpItemEqualityComparer methods. You will see the algorithm used in .NET 4.0 iterates over both collections. So it runs in O(n+m), but our modified solution runs in O(Min(n,m)), where 'n' and 'm' are lengths of collections.
Please note the Linq Intersect method is not evaluated when the method is called, but each time the resulting IEnumerable is used. And also please note that if the source collection is modified after calling the Intersect method and before using the resulting IEnumerable the change is taken into effect, which can be unwanted behaviour.