/azp run

Very nice one!!

Possible to avoid ConcurrentDictionary? IMHO it affects very badly animations scenarios, triggering GC due to its allocation mechanics, thus creating messy lag spikes during animations.
Once one starts a gaming loop that might come into play.

Maybe add a lock to a Dictionary.. Just thinking.

Is it possible to use System.Runtime.Caching.MemoryCache?

https://learn.microsoft.com/dotnet/api/system.runtime.caching.memorycache

Not sure if this is a good thing or not? Do people use this API? Is this sufficient?

/azp run

I didn't want to introduce another dependency. But I can try it and see what the benchmarks say.

A Dictionary with lock was a bit faster than the ConcurrentDictionary, but not very much. What I actually planned, but didn't find the time to is to look at the source of System.Runtime.Caching and see if I can do something similar.

I tested System.Runtime.Caching.MemoryCache but it has several drawbacks:

• it uses a string as key
• it stores an object which must be boxed

Both make it slower than the Dictionary<int, Tuple>.

Here are the benchmarks with the cache variants:

The project with the benchmarks for the various variants is on https://github.com/MichaelRumpler/SkiaTextRendering.

As you can see the simple Dictionary with a lock was always fastest with the least amount of memory used. So I changed it to this now.

the simple Dictionary with a lock was always fastest

In comparsion with the ConcurrentDictionary this is only true, as long as you don't use the specialized concurrent access methods like GetOrAdd, TryGetValue, TryUpdate and TryRemove. If you'd implement them using a simple lock statement, the ConcurrentDictionary implementation would be way faster. I can tell this, because I've implemented it just a few days ago, and benchmarks showed me a huge performance difference - so I removed my implementation with lock, finally, because 5.000us (Dictionary with lock) vs 79us (ConcurrentDictionary) during heavy multithreading doesn't really need a discussion - but for that result I've used the ConcurrentDictionary different.

Anyway these are my tests results when comparing different thread-safe dictionary access methods using max. 8 threads:

Dictionary is being used with a simple lock just as you do. ConcurrentDictionary is the .NET implementation using AddOrUpdate, and finally ConcurrentLockDictionary is my implementation of the ConcurrentDictionary interface using an underlying Dictionary with lock. The first 3 tests only work with a single item, while the ManyItems tests contain ushort.MaxValue << 3 items, which are being updated sequential using Parallel.For. The tests ending with ManyItemsRnd use random access. The ManyItems* tests are where the ConcurrentDictionary can gain most points because of its data and access locking management.

However, it depends on the ConcurrentDictionary usage, if it has advantages or not. But anyway, a ConcurrentDictionary uses way more memory than a Dictionary does (which is not visible in the test results 'cause I use static instances).

Btw. find my tests here, if you want.

When it's only about a few items, Dictionary with lock should be fine - otherwise ConcurrentDictionary may outperform.

/azp run