tags:

views:

797

answers:

5

Are enum types faster/more efficient than string types when used as dictionary keys?

IDictionary<string,object> or IDictionary<enum,object>

As a matter of fact, which data type is most suitable as a dictionary key and why?

Consider the following: NOTE: Only 5 properties for simplicity

struct MyKeys
{
   public string Incomplete = "IN"; 
   public string Submitted = "SU"; 
   public string Processing="PR"; 
   public string Completed = "CO"; 
   public string Closed = "CL";   
}

and

enum MyKeys
{
   Incomplete, 
   Submitted, 
   Processing, 
   Completed, 
   Closed
}

Which of the above will be better if used as keys in a dictionary!

+4  A: 

Certainly the enum version is better (when both are applicable and make sense, of course). Not just for performance (it can be better or worse, see Rashack's very good comment) as it's checked compile time and results in cleaner code.

You can circumvent the comparer issue by using Dictionary<int, object> and casting enum keys to ints or specifying a custom comparer.

Mehrdad Afshari
Performance-wise it might not really be true (surprisingly) - http://ayende.com/Blog/archive/2009/02/21/dictionaryltenumtgt-puzzler.aspx
Rashack
You can always specify your own comparer. That's not an issue with Dictionary or enum, but the comparer
Mehrdad Afshari
+2  A: 

Use enum to get cleaner and nicer code, but remember to provide a custom comparer if you are concerned with performance: http://ayende.com/Blog/archive/2009/02/21/dictionaryltenumtgt-puzzler.aspx .

skolima
+1  A: 

I think you should start by focusing on correctness. This is far more important than the minimal difference between the minor performance differences that may occur within your program. In this case I would focus on the proper representation of your types (enum appears to be best). Then later on profile your application and if there is a issue, then and only then should you fix it.

Making code faster later in the process is typically a straight forward process. Take the link that skolima provided. If you had chosen enum, it would have been a roughly 10 minute fix to remove a potential performance problem in your application. I want to stress the word potential here. This was definitely a problem for NHibernate but as to whether or not it would be a problem for your program would be solely determined by the uses.

On the other hand, making code more correct later in the process tends to be more difficult. In a large enough problem you'll find that people start taking dependencies on the side effects of the previous bad behavior. This can make correcting code without breaking other components challenging.

JaredPar
A: 

May not apply but...

Be aware that enums are compiled as constants which may cause redeployment of all assemblies which reference the enum if it is altered. (i.e. the constant is hardcoded in at compile time to all assemblies that use it).

Edward
A: 

I would guess that the enum version is faster. Under the hood the dictionary references everything by hashcode. My guess is that it is slower to generate the hashcode for a string. However, this is probably negligibly slower, and is most certainly faster than anything like a string compare. I agree with the other posters who said that an enum is cleaner.

Steve