18

Possible Duplicate:
count vs length vs size in a collection
Array.Length vs Array.Count

I declared this array:

int[] misInts = new Int[someNumber];

/* make some happy operations with the elements in misInts */

So I can get the value of SomeNumber with: misInts.Length or misInts.Count()

Arrays in C# inherit from IEnumerable. So if I have:

Func<int> misIntsF = Enumerable.Range(0, someNumber).Select(c=> /* make some happy operations that return Integers */);

I am told that if I make misIntsF.Count() I actually execute the code in the Lambda expression, get the results and count them. But the array misInts doesn't have a Lambda expressión.

Is misInts.Count() more memory consuming than misInts.Length? What are the differences between misInts.Count() and misInts.Length?

Community
  • 1
  • 1
Broken_Window
  • 1,916
  • 3
  • 19
  • 38
  • 4
    http://stackoverflow.com/questions/1506963/array-length-vs-array-count http://stackoverflow.com/questions/300522/count-vs-length-vs-size-in-a-collection – jrajav Dec 03 '12 at 14:42
  • @Kiyura your linked questions talk about terminology. This question asks about performance. – Rotem Dec 03 '12 at 14:43
  • (Bob Ross) - "make some happy operations with the elements in misInts" – Levi Botelho Dec 03 '12 at 14:48
  • You're right Rotem, I'm concerned about memory comsumption and performance because this is part of a larger algorithm with loops inside loops inside loops everywhere. – Broken_Window Dec 03 '12 at 14:50
  • @Rotem, this is why it's a comment and not an answer, and also why I didn't say "duplicate," it was only meant to be a pointer to information OP might not have seen yet. – jrajav Dec 03 '12 at 15:03
  • http://stackoverflow.com/questions/300522/count-vs-length-vs-size-in-a-collection – Broken_Window Dec 03 '12 at 16:47

2 Answers2

26

array.Count() is actually a call to the Enumerable.Count<T>(IEnumerable<T>) extension method.

Since this method takes an IEnumerable<T> (as opposed to ICollection<T>, which has a Count property), it needs to loop through the entire sequence to figure out how big it is.

However, it actually checks whether the parameter implements ICollection<T> (which arrays do), and, if so, returns Count directly.
Therefore, calling .Count() on an array isn't much slower than .Length, although it will involve an extra typecast.

SLaks
  • 800,742
  • 167
  • 1,811
  • 1,896
9

There is no great difference since Enumerable.Count looks first if it's castable to ICollection<T>.

MSDN:

If the type of source implements ICollection, that implementation is used to obtain the count of elements. Otherwise, this method determines the count.

Source:

ICollection<TSource> collection = source as ICollection<TSource>;
if (collection != null)
{
    return collection.Count;
}

otherwise it will enumerate the sequence to count it:

int num = 0;
using (IEnumerator<TSource> enumerator = source.GetEnumerator())
{
    while (enumerator.MoveNext())
    {
        num++;
    }
}
return num;

(source: ILSpy)

Tim Schmelter
  • 411,418
  • 61
  • 614
  • 859
  • Please not: Although you quote ILSpy as your source, this actually is *not* just an implementation detail, it indeed is documented. – Daniel Hilgarth Dec 03 '12 at 14:58
  • @DanielHilgarth: I've also linked MSDN, but since the source is quite readable in this case i have shown that instead. However, edited my answer to also quote msdn to make it clear. – Tim Schmelter Dec 03 '12 at 15:01
  • I know that you linked it. I justed wanted to emphasise the fact that it is not an implementation detail as I just had this exact discussion a few days back with someone else. And the way your answer is structured it looks like you infered this info only from the source code and not from the documentation. – Daniel Hilgarth Dec 03 '12 at 15:03
  • @DanielHilgarth: Edited my answer to make it more clear. But since Slaks has already answered it theoretically i just wanted to add something new instead of just quoting MSDN or repeat his answer in other words. Linq often appears magical for people, so it might help to see the code behind. – Tim Schmelter Dec 03 '12 at 15:06
  • +1 Thanks for adding the quote anyway :-) – Daniel Hilgarth Dec 03 '12 at 15:06