How large per list item does List get in .NET 4.0?

Question

I know that it takes 4 bytes to store a uint in memory, but how much space in memory does it take to store List<uint> for, say, x number of uints?

How does this compare to the space required by uint[]?

`List` will be backed by a `uint[]`, so it will certainly be slightly bigger in-memory, to support its additional properties. Do you find yourself running out of memory when using a `List`? — dlev, Sep 09 '11 at 19:02
possible duplicate of [Is it worthwhile to initialize the collection size of a List if it's size reasonably known?](http://stackoverflow.com/questions/2247773/is-it-worthwhile-to-initialize-the-collection-size-of-a-listt-if-its-size-reas) — Hans Passant, Sep 09 '11 at 19:11
@Hans Passant: Yes, I think that is pretty much a duplicate. Btw: Your answer to the question is great — Philip Daubmeier, Sep 09 '11 at 19:28

score 3 · Answer 1 · answered Sep 09 '11 at 19:10

3

There is no per-item overhead of a List<T> because it uses a T[] to store its data. However, a List<T> containing N items may have 2N elements in its T[]. Also, the List data structure itself has probably 32 or more bytes of overhead.

answered Sep 09 '11 at 19:10

Gabe

84,912
12
139
238

And if I remember correctly a `List` doesn't shrink automatically. One needs to call `TrimExcess` to trigger a reduction of the capacity. – CodesInChaos Sep 09 '11 at 19:17
@Code Yep. `Remove()` and `RemoveAt()` just shift the contents of the internal array and replace the removed item with `default(T)`. – dlev Sep 09 '11 at 19:20

score 1 · Answer 2 · answered Sep 09 '11 at 19:06

1

You probably will notice not so much difference between T[] and list<T> but you can use

System.GC.GetTotalMemory(true);

before and after an object allocation to obtain an approximate memory usage.

answered Sep 09 '11 at 19:06

Felice Pollano

32,832
9
75
115

score 0 · Answer 3 · edited May 23 '17 at 12:12

List<> uses an array internally, so a List<uint> should take O(4bytes * n) space, just like a uint[]. There may be some more constant overhead in comparison to a array, but you should normally not care about this.

Depending on the specific implementation (this may be different when using Mono as a runtime instead of the MS .NET runtime), the internal array will be bigger than the number of actual items in the list. E.g.: a list of 5 elements has an internal array that can store 10, a list of 10000 elements may have an internal array of size 11000. So you cant generally say that the internal array will always be twice as big, or 5% bigger than the number of list element, it may also depend on the size.

Edit: I've just seen, Hans Passant has described the growing behaviour of List<T> here.

So, if you have a collection of items that you want to append to, and you cant know the size of this collection at the time the list is created, use a List<T>. It is specifically designed for this case. It provides fast random access O(1) to the elements, and has very little memory overhead (internal array). It is on the other hand very slow on removing or inserting in the middle of the list. If you need those operations often, use a LinkedList<T>, which has then more memory overhead (per item!), however. If you know the size of you collection from the beginning, and you know that is wont change (or just very few times) use arrays.

How large per list item does List get in .NET 4.0?

3 Answers3