IDictionary or NameValueCollection

Question

I have a scenario where-in I can use either NameValueCollection or IDictionary. But I would like to know which one will be better performance-wise.

-- Using NameValu

Answer 1

A NameValueCollection in .NET is basically what's used for QueryStrings to hold key/value pairs. The biggest difference is when two items with the same key are added. With IDictionary, there are two ways to set a value. Using the .Add() method will throw an error on a duplicate key when the key already exists. But simply setting the item equal to a value will overwrite the value. This is how IDictionary handles duplicate keys. But NameValueCollection will add values like this: "value1,value2,value3". So the existing item value gets appended with a comma, then the new value appended to it each time.

It seems to me that this NameValueCollection was built specifically for QueryString use and access. A QueryString like "?a=1&b=2&a=3" in .NET will yield a result of item["a"] = "1,3". This difference of how duplicate keys are treated is the 'real' difference, that is, the biggest difference between the two.

I suspect that a NameValueCollection also does not use any hash table for rapid access of keys when the collection is large because this access is slower for small collections than without the hash table. I have not found definitive information that states whether a NameValueCollection does or does not use a hash table to access the keys. I do know that an IDictionary uses a hash table so that accessing keys in an IDictionary with many keys is quite fast. So i suspect that a NameValueCollection is faster for small collections than an IDictionary. If my guess is correct, then it wud mean a NameValueCollection shud by no means be used for large collections since the larger it is, it massively slows down without a hash table to access the keys.

For the number of keys in a querystring, this number is normally very small, so i wud guess the NameValueCollection does not use hashes, for better performance. But if Microsoft designed things for performance, and for what's best for their users, Windows wud be so different than it is today. So we can't assume anything that 'shud be'.

Also, i want to clarify an incorrect claim by the most popularly voted answer to this question. Kateroh's comment below the incorrect answer says it well enuf, that i don't need to add anything to it. But i repeat Kateroh's comment here so just maybe more people will realize that the most popular answer is wrong. Kateroh correctly states:

• According to this msdn article about NameValueCollection: https://msdn.microsoft.com/en-us/library/system.collections.specialized.namevaluecollection.aspx "Collections of this type do not preserve the ordering of element, and no particular ordering is guaranteed when enumerating the collection." – kateroh Mar 4 '11 at 18:38

Answer 2

I agree with fatcat and lomaxx (and up-voted for both answers). I would add that performance of collection types should most likely be the last consideration when choosing between collection types. Use the type that most fits your usage needs. If you are in a performance critical section of code (and most likely, you're not), then the only answer is to measure each case - don't believe the Interweb, believe the numbers.

Answer 3

These collection types are not exactly interchangeable: NameValueCollection allows access via integer indexes. If you don't need that functionality, you shouldn't use a NameValueCollection as indexing doesn't come "for free".

Depending on the number of strings you're looking at, I would consider either Hashtable<string, string> or IDictionary<string, string>. Krzysztof Cwalina discusses the subtleties here: http://blogs.gotdotnet.com/kcwalina/archive/2004/08/06/210297.aspx.

Answer 4

The other advantage of IDictionary is that it's not implementation specific unlike NameValueCollection.