5

I was reading an article about array vs list, and the author says that an array is worse than a list, because (among other things) an array is a list of variables, but to me a list is also a list of variables. I mean, I can still do list[3] = new Item().

Actually, I have always somehow saw a List<T> like a wrapper for an array that allows me to use it easily without caring about handling its structure.

What are the internal differences between a T[] and a List<T> in terms of heap/stack memory usage?

trincot
  • 317,000
  • 35
  • 244
  • 286
vtortola
  • 34,709
  • 29
  • 161
  • 263
  • 2
    Technically, a `List` IS a wrapper for an array. It holds a reference to an array internally, so an List consumes more memory (assuming that the internal array is completely filled). But this difference is very small (List consumer somewhere around 20 to 30 bytes of extra memory), so don't optimize prematurely. – Steven Dec 05 '13 at 13:52
  • So is the author wrong and there is no difference regarding that matter? – vtortola Dec 05 '13 at 13:56
  • 2
    He clearly states so in the blog post, "one might reasonably point out that `List` is a mass of mutable state too". Of course it is. Heap usage is not a detail you can completely ignore, and average overhead is *lots* more than 30 bytes in common usage. Well covered in [this answer](http://stackoverflow.com/a/2248188/17034). – Hans Passant Dec 05 '13 at 14:19

2 Answers2

2

Since an array is a static structure, after the initialization, it allocates the memory that you've demanded.

int arr[5];

For example here there are 5 int objects created in memory. But when you use lists, according to its implementation, it gives you first an array with predefined capacity. And while you are adding your elements, if you exceed the capacity then it scales up. In some implementations it just doubles its size, or in some implementations it enlarges itself when the granted capacity is half full.

Tolga Evcimen
  • 7,112
  • 11
  • 58
  • 91
1

The author's point about a "list of variables" wasn't about memory. It's that an array contains your internal variables, and returning it allows them to be reassigned by the caller. It comes down to this:

Only pass out an array if it is wrapped up by a read-only object.

If you pass out an internal List<T>, you have the same problem, but here's the key:

We have an extensibility model for lists because lists are classes. We have no ability to make an “immutable array”. Arrays are what they are and they’re never going to change.

And, at the time the article was written, the IReadOnlyList interface didn't exist yet (.NET 4.5), though he probably would have mentioned it if it had. I believe he was advocating implementing an IList<T> that would simply throw an exception if you tried to use the setter. Of course, if the user doesn't need the ability to access elements by index, you don't need a list interface at all -- you can just wrap it in a ReadOnlyCollection<T> and return it as an IEnumerable<T>.

nmclean
  • 7,564
  • 2
  • 28
  • 37