In IEnumerable extensions - why is only Count() optimized for ICollection?

Question

After de-compiling the Linq IEnumerable extension methods I was glad to see that
the Count() method, prior to trying to iterate the whole enumerable, attempts to downcast it to an ICollection or an ICollection<T> e.g:

    public static int Count<TSource>(this IEnumerable<TSource> source) {

        if (source == null) throw Error.ArgumentNull("source");

        ICollection<TSource> collectionoft = source as ICollection<TSource>;

        if (collectionoft != null) return collectionoft.Count;

        ICollection collection = source as ICollection;

        if (collection != null) return collection.Count;

        int count = 0;

        using (IEnumerator<TSource> e = source.GetEnumerator()) {
            checked {
                while (e.MoveNext()) count++;
            }
        }
        return count;
    }

Why isn't this happening in Any()? won't it benefit from using .Count > 0 instead of creating an array enumerator?

Answer 1

Not all collections provide O(1) access for Count property. For example accessing count property of ConcurrentQueue<T> is O(n). So that optimization will make it worse and hence shouldn't be called as optimization.

Not only ConcurrentQueue<T>, Almost all concurrent collections (ConcurrentDictionary<TKey,TValue>, ConcurrentStack<T> etc) falls in this category

May be that is why they decided not to do it.