[Mono-dev] Trivial Enumerable Optimizations

[Jonathan Pryor]

On Thu, 2008-05-08 at 15:36 -0400, Jonathan Pryor wrote:
> System.Core.Enumerable already has a set of "obvious" optimizations in
> which the IEnumerable<T> argument is checked to see if it's another
> interface and the implementation is "switched" based on the runtime
> type, e.g.

A related optimization for LongCount() occurred to me as well, so first
a question: is it safe to assume that if ICollection<T> is implemented
that ICollection<T>.Count will be valid?

In short, does implementing ICollection<T> guarantee that the collection
is limited to int.MaxValue elements?

Obviously not: arrays implement ICollection<T>, yet may support elements
with more than int.MaxValue elements.  (Except no one (until now) has
actually supported arrays with > int.MaxValue elements, so perhaps this
isn't quite so obvious.)

So what are the semantics for ICollection<T>.Count when the collection
contains more elements than int.MaxValue?  MSDN doesn't say.  MSDN
doesn't even state that ICollection<T>.Count should be >= 0, for that
matter:

    http://msdn.microsoft.com/en-us/library/5s3kzhec.aspx

So is it possible to further optimize the LongCount() extension method?
Perhaps something like this?

    public static long LongCount<TSource> (this IEnumerable<TSource> source)
    {
       // as before...
       ICollection<TSource> c = source as ICollection<TSource>;
       if (c != null) {
           try {
               return c.Count;
           }
           catch {
               // ignore; collection has > int.MaxValue elements, 
               // so count manually below.
           }
       }
       // as before...
    }

This will suffer an obvious performance penalty if the collection has
over int.MaxValue elements (assuming .Count throws an exception when
that happens), but as most (currently all?) collections will have less
than int.MaxValue elements, this should be a performance win.

Thoughts?

 - Jon