A faster replacement to the Dictionary

Question

I need a fast replacement for the System.Collections.Generic.Dictionary. My application should be really fast. So, the repl

Answer 1

Don't forget, you're timing the Dictionary constructor in that code as well. I did a test, moving the call to the constructor out of the measurement, and looped 10 times. Here's my test code:

for (int i = 0; i < 10; i++)
{
    Dictionary<string, string> test = new Dictionary<string, string>();

    System.Diagnostics.Stopwatch watch = System.Diagnostics.Stopwatch.StartNew();

    test.Add("fieldName", "fieldValue");
    test.Add("Title", "fieldavlkajlkdjflkjalkjslkdjfiajwelkrjelrkjavoijl");

    Console.WriteLine(watch.Elapsed);
}

Console.ReadKey();

Below are the results:

00:00:00.0000607
00:00:00.0000025
00:00:00.0000015
00:00:00.0000015
00:00:00.0000016
00:00:00.0000017
00:00:00.0000016
00:00:00.0000016
00:00:00.0000016
00:00:00.0000015

I'm not sure how much faster you could get than that...

Update

Looks like this mirrors Jon Skeets results too...JIT.

Answer 2

Odds are you are not going to find anything much faster than Dictionary. I would just use Dictionary. Then, when you see you are not meeting your perf goals, and a profiler indicates that adding/removing from Dictionary are your bottlenecks you can consider replacing with a more targeted class.

Note that features such as LINQ due not incur any performance loss if you do not use them.

Answer 3

I agree with Jon Skeet's supposition that this is most likely JIT compilation.

That being said, I wanted to add some other information here:

Most of the speed issues relating to using Dictionary<T,U> are not related to the implementation of Dictionary. Dictionary<T,U> is VERY fast, out of the box. It would be difficult to beat it.

Speed issues relating to Dictionary instances are almost always actually hash code implementation issues. If you're having speed issues when using Dictionary<MyCustomClass,MyValue>, revisit the GetHashCode() implementation you have defined on MyCustomClass. This is even more critical if you're using a custom struct as your key.

In order to get good performance out of Dictionary, GetHashCode() should be:

1. Fast
2. Able to provide hash codes that generate few conflicts. Unique instances should, when possible, generate unique hash values.

If you get that right, I think you'll be very happy with the default Dictionary implementation.

Answer 4

How many items do you plan to add to the dictionary? While Dictionary/Hashtable is usually the fastest, depending on what you are doing, there may be something faster (aka better suited) than a Hashtable (the underlying structure in a Dictionary). Based on the usage, it's possible that SortedList could be faster if combine with some kind of Skip List or even a self-balancing tree or tries. Especially if you wish to return a range of values rather than a single value.

A Hashtable is a good fit when:

1. You know how many items you intend to store before population of the table begins. Dynamic resizing will be very painful!
2. You have a good hash algorithm with even distribution, which .NET does
3. There is a good mechanism in place for collision resolution, which .NET does
4. You are looking for a single value
5. You can guarantee that all values will be unique

If you're doing some compression, for example, a RB-Tree is better than a Hashtable.

Source: http://en.wikipedia.org/wiki/Hashtable#Dynamic_resizing