Like my last post, "Materializing an Enumerable" this may be a bit academic, but as a linq geek, whether I should use .
.ToArray() is something the piques my curiosity. Most of the time when I return
IEnumerable<T> i want it to be in a threadsafe manner, i.e. i don't want the list to change underneath the iterator, so I return a unique copy. For this I have always used
.ToArray(), since it's immutable and I figured it was leaner.
Finally having challenged this assumption, it turns out that
.ToList() is theoretically faster for sources that are not
ICollection<T>. When the final count is known, as is the case with
.ToArray() create an array under the hood for storage that is sufficiently large and copy the source into the destination. When the count isn't known however, both allocate an array and write to it, copying the contents to a larger array anytime the size is exceeded. So far, both are nearly identical in execution. However, once the end of the source is reached,
.ToList() is done, while
.ToArray() does one more copy to return a properly sized array. Of course, the overhead of iterating on that source, which is more than likely hitting some I/O or Computation barrier, means that in terms of measurable performance difference, again, both are identical.
It is still true that a
List<T> object uses more memory than an
T, but even that difference is almost always going to be irellevant as the collections size is insignificant compared to the items it contains. That means that using .
.ToArray() to create an
IEnumerable<T> is really a matter of personal preference.