Optimizing Jint part 6: DictionarySlim is coming to town

The past weekend I read about an interesting pull request which is bringing a new type of dictionary with great interest. The idea of creating a new, simpler and enhanced version, now called DictionarySlim, original spun from the famous k-nucleotide benchmark where .NET had some trouble performing well with the built-in Dictionary. What is this new member in *Slim family?


As we know, the original Dictionary has been there a long time and comes with some baggage. Now that C# as a language supports some performance related features like ref-returns, there are things that the Dictionary could improve. However it's not always easy to alter a well-known API, even though there's an effort to back-port some of the goodies.

How does the new DictionarySlim differ from Dictionary

The API has been reduced to minimal, allowing well performing operations. You should be quite familiar with ContainsKey, TryGetValue and indexing with this[]. Indexing works using ref returns and the getter actually allows you to assign values too as you get reference to raw position for value to store.

Things to not here is that calling the indexer will actually add an item, costing space. Thus, you should always use TryGetValue to check for value presense.

How does it perform?

Here are the numbers from PR changing Jint's old, already somewhat optimized custom dictionary to slightly customized DictionarySlim:

Diff	Method	N	Mean	Gen 0/1k Op	Gen 1/1k Op	Gen 2/1k Op	Allocated Memory/Op
Old	Benchmark	500	287.9 ms	33500.0000	-	-	135.1 MB
New			251.6 ms (-13%)	29500.0000 (-12%)	-	-	119.66 MB (-11%)

As we can see, the implementation is faster than traditional Dictionary and uses less memory.

Notes from DictionarySlim code review

I noticed couple interesting tidbits when reading the review comments.

Automatic properties are costly

A review comment:

Automatic properties are one of those things that just make code bigger and slower. You pretty much never want to use them if you care about peak performance. They also make it hard to see the full state in the source - that's also not desirable if you optimize for peak performance.

Manual inlining 

Another interesting tidbit from the review was to manually inline couple simple methods that already haved AggressiveInlining, just to make sure they are always inlined.

So this is why there will now someday be a DictionarySlim alternative, available as part separate specialized collections package Microsoft.Experimental.Collections.