Which is faster/more efficient: Dictionary<string,object> or Dictionary<enum,object>?

Question

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!

Answer 1

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.

Answer 2

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.