Is it possible to add a method where it'll provide rough memory that is being used by the cache stance? about bitfaster.caching HOT 2 CLOSED

To accomplish this, two things would be required:

1. A mechanism to enumerate all the items in the cache.
2. Code that is able to analyze the size of an arbitrary type instance. This is relatively straightforward for classes/structs which do not contain references to other class instances. To contend with a graph of objects, the analyzer would need to be able to detect duplicates and avoid getting stuck in a loop analyzing cyclic references.

I can add an event solving part 1. This would enable you to have a background thread that periodically wakes up, enumerates all the items, then uses 2 to compute total size. I am philosophically opposed to a cache looking like a collection, but I understand this is useful for diagnostic purposes, and have already added a property to enable enumerating all the cached keys.

Writing code to solve part 2 would look something like this, but it won't scale well as reference count increases because resizing the hashset will be expensive. A slightly hackier way would be to serialize to binary, but that means all items must be serializable. Note that if your cached items reference a common global static (and these exist within framework types), such objects should be ignored since they do not contribute to item size and shouldn't be double counted. To handle things like this, you would need to reflect on the item type of each reference and filter by namespace.

I would like to keep this library focused on caching, and provide the hooks that make it useful/enable consumers. So, I can add the item enumeration, and that will enable you to roll your own memory estimate solution. You can use either of the above approaches to estimate item size if a relatively simple approach works in your use case. A generalized efficient, robust and configurable solution to 2 above is probably a dedicated NuGet package in itself.

from bitfaster.caching.

Sorry for the late reply. Yes, I think adding this feature will defeat the purpose of the library. Didn't really thought about it until you explained the reasons behind it. But having an event I think is an ok so that the consumers are aware of the penatlies of using it.

from bitfaster.caching.