IEnumerable is empty?

Question

I know it probably doesnt matter/affect performance for the most part but I hate the idea of getting an IEnumerable and doing .Count(). Is there a IsEmpty or NotEmpty or some function? (similar to stl empty())

Answer 1

Without any need of LINQ, you can do following:

bool IsEmpty(IEnumerable en)
{
    foreach(var c in en) { return false; }
    return true;
}

Answer 2

On IEnumerable or IEnumerable<T>, no.

But it really doesn't make much sense. If a collection is empty and you try to iterate over it using IEnumerable, the call to IEnumerator.MoveNext() will simply return false at no performance cost.

Answer 3

You want IEnumerable.Any() extension method (.Net Framework 3.5 and above). It avoids counting over the elements.

Answer 4

I don't think so, that's what Count is for. Besides, what will be faster:

1. Accessing a Property and retrieving a stored Integer
2. Accessing a Property and retrieving a stored Boolean

Answer 5

You can use extension methods such as Any() or Count(). Count() is more costly than Any(), since it must execute the whole enumeration, as others have pointed out.

But in the case of lazy evaluation (e.g. a method that uses yield), either can be costly. For example, with the following IEnumerable implementation, each call to Any or Count will incur the cost of a new roundtrip to the database:

IEnumerable<MyObject> GetMyObjects(...)
{
    using(IDbConnection connection = ...)
    {
         using(IDataReader reader = ...)
         {
             while(reader.Read())
             {
                 yield return GetMyObjectFromReader(reader);
             }
         }
    }
}

I think the moral is:

• If you only have an IEnumerable<T>, and you want to do more than just enumerate it (e.g. use Count or Any), then consider first converting it to a List (extension method ToList). In this way you guarantee to only enumerate once.

• If you are designing an API that returns a collection, consider returning ICollection<T> (or even IList<T>) rather than IEnumerable<T> as many people seem to recommend. By doing so you are strengthening your contract to guarantee no lazy evaluation (and therefore no multiple evaluation).

Please note I am saying you should consider returning a collection, not always return a collection. As always there are trade-offs, as can be seen from the comments below.

• @KeithS thinks you should never yield on a DataReader, and while I never say never, I'd say it's generally sound advice that a Data Access Layer should return an ICollection<T> rather than a lazy-evaluated IEnumerable<T>, for the reasons KeithS gives in his comment.

• @Bear Monkey notes that instantiating a List could be expensive in the above example if the database returns a large number of records. That's true too, and in some (probably rare) cases it may be appropriate to ignore @KeithS's advice and return a lazy-evaluated enumeration, provided the consumer is doing something that is not too time-consuming (e.g. generating some aggregate values).

Answer 6

Keep in mind that IEnumerable is just an interface. The implementation behind it can be very different from class to class (consider Joe's example). The extension method IEnumerable.Any() has to be a generic approach and may not be what you want (performance wise). Yossarian suggests a means that should work for many classes, but if the underlying implementation does not use 'yield' you could still pay a price.

Generally, if you stick to collections or arrays wrapped in an IEnumerable interface, then Cristobalito and Yossarian probably have the best answers. My guess is the built-in .Any() ext method does what Yossarian recommends.