MECM MemoryCache performance; split string keys into separate collection #111502
+154
−32
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Historically, MECM
MemoryCache
uses a single lookup ofobject
types. The runtime includes advanced key re-hashing in the relevant dictionary types, but this is restricted toTKey
===typeof(string)
, which won't apply. We resolve this by splitting the collection into two - one forstring
keys, one for everything else. This allows thestring
keys (which is most of them, in many cases) to be re-hashed automatically. This improves performance in catastrophic key collision scenarios.MECM is an OOB NuGet package with net462 and netstandard2.0 targets (in addition to up-level). On down-level TFMs, where this re-hashing isn't available, we can still mitigate against the impact of this by using Marvin; this means that collision scenarios are different per execution, reducing risk by repeatable scenarios.
Changes:
string
and non-string
keys into separate collections, to allow re-hashing ofstring
keysNote:
ReadOnlySpan<char> key
API: [API Proposal]: M.E.C.M. MemoryCache - add ReadOnlySpan<char> get API #110504