A few small issues

[theodorzoulias]

I would like to report some issues with the FastCache<TKey, TValue> class, after inspecting briefly the source code.

1. The internal TtlValue is a class. It could be a struct (more lightweight, less pressure on the garbage collector).
2. It's possible for the _EvictExpired callback to be invoked in an overlapping manner, if the cache contains many keys and the cleanupJobInterval is very small.
3. The FastCache<TKey, TValue> is not disposable, so there is no way to stop the timer. The timer will keep ticking until the class is garbage collected.
4. The FastCache.GetOrAdd does not use the ConcurrentDictionary.GetOrAdd overload that has a TArg generic argument, and so it results in an allocation of a closure on each invocation.
5. The full functionality of the underlying ConcurrentDictionary<TKey, TValue> is not available. For example the FastCache<TKey, TValue> exposes a void Remove(TKey key) method, and not a bool TryRemove (TKey key, out TValue value) method.

[alex-jitbit]

All good points, I'm on it

[theodorzoulias]

​​Regarding the point 5, I guess that the design goal for the FastCache<TKey, TValue> class was to be an alternative for the MemoryCache, so it makes sense to imitate that API and not the API of the ConcurrentDictionary<TKey, TValue>. I was probably confused from the phrase "after all, it's just a dictionary" in the readme file.

[alex-jitbit]

I looked closer at suggestion 1 (struct vs class):

1. default GetHashCode for values types is tricky, https://stackoverflow.com/a/5927853/56621
2. comparer will be slower since comparing ref-type compares the reference, and for values type I'd have to implement my own Hashing, which will slow things down, also see above
3. finally, I wrote a benchmark to test lookup speeds and allocations - almost no difference at all. 7.61KB vs 7.62KB. On longer collations class even wins.