[Feature] Add event for when an item is expired.

[niemyjski]

We have a use case where we need to get notified when an item is evicted, would it be possible to add an event one could wire up to?

[bitfaster]

Possible, but obviously will come with some perf/code size penalty. Right now there is FastConcurrentLru and ConcurrentLru - the fast version has all hit counting logic eliminated to squeeze out the absolute fastest perf/smallest code size. I will look at incorporating an OnItemRemoved event into IHitCounter such that it would only be available in ConcurrentLru/ConcurrentTLru, and the Fast versions would then still have everything stripped out. That way you still get to choose between best possible perf vs instrumentation.

The event would fire passing the key and the value, and would fire before the item is disposed by the cache (if it implements IDisposable).

If I can implement it with minimal overhead, I will add it. If it's too expensive, I would likely not add the feature. One reason these caches are faster than MemoryCache etc. is that all the ancillary features like events that not everyone uses are eliminated from the code. If it ends up having equal perf to MemoryCache, may as well just use MemoryCache instead.

[niemyjski]

There is very little if any overhead if the event isn't subscribed too. Thanks -Blake Niemyjski

…

On Wed, Nov 10, 2021 at 4:14 PM Alex Peck ***@***.***> wrote: Possible, but obviously will come with some perf/code size penalty. Right now there is FastConcurrentLru and ConcurrentLru - the fast version <https://github.com/bitfaster/BitFaster.Caching/wiki/What-are-the-'fast'-LRU-variants%3F> has all hit counting logic eliminated to squeeze out the absolute fastest perf/smallest code size. I will look at incorporating an OnItemRemoved event into IHitCounter such that it would only be available in ConcurrentLru/ConcurrentTLru, and the Fast versions would then still have everything stripped out. That way you still get to choose between best possible perf vs instrumentation. The event would fire passing the key and the value, and would fire before the item is disposed by the cache (if it implements IDisposable). If I can implement it with minimal overhead, I will add it. If it's too expensive, I would likely not add the feature. One reason these caches are faster than MemoryCache etc. is that all the ancillary features like events that not everyone uses are eliminated from the code. If it ends up having equal perf to MemoryCache, may as well just use MemoryCache instead. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#89 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZFIZOX5TMRJWDURK3M73ULLVFJANCNFSM5HXWM73Q> .

[bitfaster]

I haven't previously studied how events or multicast delegates work behind the scenes - I'm investigating the IL and assembler and measuring some scenarios to validate. I use this library in a production system where performance matters, so I'm trying to do a thorough job of analyzing the impact of any additional code. I'm sure you are correct, but it seems sensible to measure and quantify your statement.

For .NET 6 the implementation I have in the PR has an overhead of 16 instructions which increases the JITted code size by 67 bytes. Variance in run time with/without the event is within the noise floor for minimal benchmarks, but they clearly fit into the instruction cache on my machine and would not be affected by the code size increase.

The code that increased in size is the 'Move' method, which is not invoked for cache hits when size is stable. I tend to focus on the hit code path, since it determines the speedup gained by caching for a high hit rate on a 'hot' item. I have also validated that the JIT can elide all the extraneous code when using the null policy, so the Fast LRU variant code size/perf is preserved.

[tcsaddul]

I suggest this feature should not be included in the FastConcurrentLru for performance reasons. The ConcurrentLru can have it though which can be used as a kind of having more features than the FastConcurrentLru.

[bitfaster]

ItemRemoved event change is now merged, it will be in the next release.

[bitfaster]

FYI NuGet package version 1.0.6 contains the ItemRemoved event.