Repository navigation
Clean-up: Reduce repeated checks for ICollection<T>.Count, Iterator.GetCount and ICollection.Count #135269
Description
Within LINQ there are multiple places where the code adds optimised paths for the ICollection<T>, Iterator<T> and ICollection in order to get the Count of the source collection. These can be collapsed to utilise the Enumerable.TryGetNonEnumeratedCount method, reducing repeated code.
This clean-up task has the advantage that adding a new optimisation (say, for IReadOnlyCollection<T>) to TryGetNonEnumeratedCount would accrue to all users of this method.
Activity
dotnet-policy-service commentedon Oct 6, 2026
Tagging subscribers to this area: @dotnet/area-system-collections
See info in area-owners.md if you want to be subscribed.
MikeBarker-MSFT commentedon Oct 6, 2026
Specific cases:
Enumerable.Any<TSource>(this IEnumerable<TSource>)Enumerable.Count<TSource>(this IEnumerable<TSource>)Enumerable.AppendPrepend1Iterator<TSource>.GetCount(bool onlyIfCheap)Enumerable.AppendPrependN<TSource>.GetCount(bool onlyIfCheap)Enumerable.DefaultIfEmptyIterator<TSource>.GetCount(bool onlyIfCheap)Enumerable.OrderedIterator<TElement>.GetCount(bool onlyIfCheap)huoyaoyuan commentedon Oct 6, 2026
#135270 (comment)
For speed-optimized LINQ, it's not the goal to make code minimal. Generally, "clean-up" should not be performed without solid performance data. Different methods can employ the same series of checks, but optimized with different preferences.
JakeYallop commentedon Oct 6, 2026
I feel like there have been a few PRs in the past that have considered doing something like this, and there have been reasons given for why not to do it. For example, #99218 removed
TryGetNonEnumeratedCount