Is the C# compiler able to optimize a statement like someEnumerable.Count() < 2?

Question

Let's say I have code like:

if (someEnumerable.Count() < 2) {
   // Do something
}

Would this result in someEnumerable being iterated over fully, or would evaluation complete if Count() reaches a second item in the enumerable?

Moriahmoriarty

No, but Skip(1).Any() is about the same length... – Flocculent

Good point! It's just an example though, I was curious how far compiler optimization has come - if something like this can be caught/optimized or if that's a pipe dream. – Moriahmoriarty

That's simply not the kind of thing the C# compiler does. There are a very few things that it will optimize in terms of expected library behavior - I seem to remember that for (x, y, z) = (a, b, c) it doesn't actually create the ValueTuple - but I would never expect it to change this code. – Inchworm

I would accept that as an answer. :) – Moriahmoriarty

I'm not entirely sure what you're asking, but Count only iterates over the enumerable as a last resort. source.dot.net/#System.Linq/System/Linq/Count.cs,11 – Subedit

Last resort being that it's not an ICollection of any kind. So depends where you got your IEnumerable from. – Hoary

Yeah, Julia mentioned the IEnumerable won't be iterated unless necessary. That's not a compiler optimization, that's due to how the 'Count' method is implemented. When you talk about compiler optimizations, that implies the compiler outputting something different to what you wrote but functionally equivalent. When Jon says there's only a few scenarios where that would happen, it's because most optimizations are implemented in code in the BCL – Willyt

It's usually not safe for the compiler to assume it can rearrange linq statements for performance. Skip(1).Any() should be equivalent here, but it is not always. When using Entity Framework, enumerating the source would cause all entries to be loaded into memory. Reordering that statement would mean that a successive call to Find() would be a cache miss instead of a hit. That's potentially introducing bugs – Willyt

someEnumerable.Count() is just a method which is called and the compiler will not change the behavior of a method. Use the right method if you don't want to count something but just want to know if there is not more than one: !someEnumerable.Skip(1).Any() – Conglobate

Answer 1

There is no compiler optimization regarding the behavior of methods. If at all that would be a runtime optimization of the method itself. But since Enumerable.Count doesn't know in which context it is used, it cannot change it's behavior.

If you don't want to count something but just want to know if there is not more than one use:

if (!someEnumerable.Skip(1).Any()) {
   // Do something
}

However, if someEnumerable is implementing ICollection<TSource> or ICollection(like arrays, lists or dictionaries) the method is optimized to simply use the Count property, so doesn't need to enumerate all items(source). Then it would be a micro optimization which hurts readability and i'd probably prefer Count() < 2.

Conglobate

Answer 2

In general, the optimizations compilers do are quite conservative because they have to work for all cases.

From the compiler's point of view there are two discrete operations here. 1) counting the elements of the sequence represented by someEnumerable and 2) comparing that count to a specific value. The compiler has no way to know if there are any side effects of enumerating the sequence (I guess it could find out, but it gets hairy pretty quickly), so an optimization like this would change the semantics of someEnumerable.Count().

For what it is worth some implementations of Count can and do use properties if available, but that's controlled by the class implementing the interface and not in general by the compiler.

Derward

That makes perfect sense - thanks! I accepted Tim's answer because it was first, but I appreciate you expanding on it. – Moriahmoriarty