The reason is that, when mentioning range
or any method of extending it, you will be calling GetEnumerator()
and iterating somehow on it.
For small lists like this, there is not much difference in performance. Things change with an enumeration of thousands of records.
Let’s go deep into the pain. Imagine this:
var range = Enumerable.Range(0, 100000);
By assigning the variable, you have already created an iterable enumeration for 100000 records. By calling:
var primeiro = range.First();
You’re calling GetEnumerator()
again, for an enumeration is not a concrete list. So much so that this gives a compilation error:
public List<MeuObjeto>()
{
for (int i = 0; i < 10; i++) {
yield return MeuObjeto();
}
}
And this works:
public IEnumerable<MeuObjeto>()
{
for (int i = 0; i < 10; i++) {
yield return MeuObjeto();
}
}
Imagine now the cost of this last function over 100000 records. And that in your case, it runs 2 times.
That’s why Resharper suggests you make the list come true. He doesn’t know what’s behind it, but assumes the worst case ever.
I’m leaving but the answer seems to be here http://stackoverflow.com/q/8240844/221800
– Maniero
Enumerable.Rage returns which object? It is a Line in the BD?
– Ricardo
No, he returns a
IEnumerable<T>
.– Jéf Bueno