Improve Enumerable.SingleOrDefault(predicate) Logic

[seanfisher]

Improve Enumerable.SingleOrDefault logic

This improves performance for the case where more than one element is found that matches the predicate, especially in large data sets.

General

Hi, I ran across the reference source for Enumerable.cs and was surprised to see an improvement opportunity. I was about to open an issue over there but then read a closed issue where they recommended opening new issues over here instead.

In the current reference source it appears that there is needless looping over the entire enumerable even if the count of elements that match the predicate is greater than one. Here's a quick one-liner example of a short-circuit exit improvement (notice the added line right after checked { count++; }), although I'm sure it could be improved even further:

public static TSource SingleOrDefault<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
{
    if (source == null) throw Error.ArgumentNull("source");
    if (predicate == null) throw Error.ArgumentNull("predicate");
    TSource result = default(TSource);
    long count = 0;
    foreach (TSource element in source)
    {
        if (predicate(element))
        {
            result = element;
            checked { count++; }
            if (count == 2) { break; }
        }
    }
    switch (count)
    {
        case 0: return default(TSource);
        case 1: return result;
    }
    throw Error.MoreThanOneMatch();
}

Let me know if this is the appropriate place for this issue. It could also be that the reference source doesn't reflect exactly what the implementation is doing, because I would expect something like the Enumerable methods would have long-since been hand-tuned for performance.

[benaadams]

It seems to be fixed in corefx?
https://github.com/dotnet/corefx/blob/master/src/System.Linq/src/System/Linq/Single.cs

However, for a performance improvement, you should be able to just open and Issue in the repository that has the source or open a PR change.

Although what reference source shows is the code for full framework/desktop so it could probably still do with this change (or to pick up corefx's Linq code)

[Petermarcu]

I'm going to move this issue to corefx. The outcome here is probably to add a ref count to get this on the list of things to consider porting to .NET Framework.

[Petermarcu]

Issue moved to dotnet/corefx #25079 via ZenHub