Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plan to support the new IBufferDistributedCache interface? #23

Open
jodydonetti opened this issue Dec 21, 2024 · 3 comments
Open

Any plan to support the new IBufferDistributedCache interface? #23

jodydonetti opened this issue Dec 21, 2024 · 3 comments

Comments

@jodydonetti
Copy link

Hi all!
Some users of my caching library FusionCache are using this IDistributedCache implementation as an L2, mainly in mobile apps and games.
I was wondering if you are planning to add support for the new IBufferDistributedCache interface to get even better perf.

@mgravell
Copy link

The short version of this change is "exactly the same thing, but without allocating a byte[] every call"; here's the SE.Redis implementation for reference: https://github.com/dotnet/aspnetcore/blob/main/src/Caching/StackExchangeRedis/src/RedisCache.cs#L694

Or the key bits from the SQL Server version (probably closer): https://github.com/dotnet/aspnetcore/blob/main/src/Caching/SqlServer/src/DatabaseOperations.cs#L313

@mqudsi
Copy link
Member

mqudsi commented Dec 22, 2024

Sure, this sounds like a decent feature to add. I'm not sure how often we'll be able to avoid allocating without looking into this further to see what the common usage patterns are like, but it's definitely worth considering!

@mgravell
Copy link

Note: if you can't avoid allocating the right sized array in at least one direction (read, write), then there would be no advantage to implementing this new interface. The relevant mechanisms already use type-testing to use the most appropriate API available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants