Generic Lists

Scott Hanselman commented that in NET 2.0, there seems to be no differences between Collection and List in the generics namespace.

I think there are two possible reasons.

• Collection<T> appears to be a replacement for CollectionBase, which provided virtual methods to detect insertions, deletions and changes.
• The new List class no longer provides any virtual methods as did the original ArrayList for performance reasons..

The new System.Generic.List class is a much better improvement over the original Everett ArrayList, not just in terms of explicit typing, but also in terms of performance and memory utilization. However, some of the advantages have been erased in the Whidbey ArrayList, because the ArrayList class has been rewritten.

• List<T> does not use any virtual methods. As a result, a number of methods such as the list indexer methods can now be inlined.
• With the default constructor, List<T> and Whidbey ArrayList do not allocate any memory for its items, so an empty list represents a very compact object--comparable in size to an empty array. (8 bytes for Array, 12 bytes for List, 16 bytes for Whidbey ArrayList) It uses the empty array trick that I wrote about in an earlier post. In contrast, earlier versions of ArrayList would allocate space for 16 items by default.
• The initial buffer size when an item is actually added is 4 items not 16 as before.
• List<T> returns an struct-based enumerator, so that iterating through foreach now involves no memory allocations at all.

 

Comments

[Patrick Smacchia]

I understand that MS provides non-virtual methods for List T in order to improve perf, and thus, needs to provide smthing like Collection T to have a base class for custom collection. However, why does Collection T is not abstract since there is no point in prefering Collection T to List T? or am I missing smthing?

In the same spirit, I suspect that the only reason for KeyedCollection K,V (which is abstract) is to provide a base class for custom dictionary. Am I right?