Performance difference when enabling auto-clone vs EasyCaching.InMemory #531

gioce90 · 2025-09-02T08:06:07Z

gioce90
Sep 2, 2025

Hi Jody,

first of all, thanks for the amazing work on FusionCache 🙌.
I’ve been experimenting with it and running some benchmarks to compare it with EasyCaching.InMemory.

From my tests, it seems that EasyCaching.InMemory has cloning (serialization on read) enabled by default, while FusionCache (of course) does not.

(this is just one run, I repeated the test multiple times with similar results)

With auto-clone disabled, FusionCache is 🚀 significantly faster than EasyCaching (in the chart this is the Default one).

With auto-clone enabled, FusionCache becomes much slower than EasyCaching.InMemory.

This makes sense, since cloning is not cheap, so it seems that EasyCaching uses a more optimized strategy here.

I also tried different serializers for the cloning:

With Newtonsoft.Json, I got the worst results (~2-3x slower).
With System.Text.Json, results are a bit better, but still about ~2x slower than EasyCaching.
With CySharp.MemoryPack, things look much better, but I’m not sure about its adoption in production. I’d also need to test more carefully that the deserialized object is exactly what I expect, and I have doubts about memory usage and potential GC pressure.

👉 My question:
Do you think there’s room for improving the auto-clone implementation in FusionCache, maybe adopting a strategy similar to EasyCaching’s ?

I think this could bring FusionCache many benefits, especially for scenarios where object immutability is important but performance is still critical.

If useful, I can share the benchmark code.

Thanks again for your work. I will wait your thoughts :)

Answered by jodydonetti

Sep 5, 2025

Hi Jody,
first of all, thanks for the amazing work on FusionCache 🙌.

Hi Gioacchino, thanks appreciate that!

I’ve been experimenting with it and running some benchmarks to compare it with EasyCaching.InMemory.

From my tests, it seems that EasyCaching.InMemory has cloning (serialization on read) enabled by default, while FusionCache (of course) does not.
(this is just one run, I repeated the test multiple times with similar results)
With auto-clone disabled, FusionCache is 🚀 significantly faster than EasyCaching (in the chart this is the Default one).
With auto-clone enabled, FusionCache becomes much slower than EasyCaching.InMemory.
This makes sense, since cloning is not cheap, so it se…

View full answer

jodydonetti · 2025-09-05T16:16:55Z

jodydonetti
Sep 5, 2025
Maintainer

Hi Jody,
first of all, thanks for the amazing work on FusionCache 🙌.

Hi Gioacchino, thanks appreciate that!

I’ve been experimenting with it and running some benchmarks to compare it with EasyCaching.InMemory.

From my tests, it seems that EasyCaching.InMemory has cloning (serialization on read) enabled by default, while FusionCache (of course) does not.
(this is just one run, I repeated the test multiple times with similar results)
With auto-clone disabled, FusionCache is 🚀 significantly faster than EasyCaching (in the chart this is the Default one).
With auto-clone enabled, FusionCache becomes much slower than EasyCaching.InMemory.
This makes sense, since cloning is not cheap, so it seems that EasyCaching uses a more optimized strategy here.

I took a brief look at their code and yes, it looks like they created their own deep cloner thing (see here), which seems to be a copy of this.

I also tried different serializers for the cloning:

With Newtonsoft.Json, I got the worst results (~2-3x slower).

With System.Text.Json, results are a bit better, but still about ~2x slower than EasyCaching.

With CySharp.MemoryPack, things look much better, but I’m not sure about its adoption in production. I’d also need to test more carefully that the deserialized object is exactly what I expect, and I have doubts about memory usage and potential GC pressure.

In general MemoryPack is among the fastest serializers (if not the fastest) and less memory hungry: having said that, as you pointed out you shoudl carefully check the behavior because it may have things that are not expected.

👉 My question: Do you think there’s room for improving the auto-clone implementation in FusionCache, maybe adopting a strategy similar to EasyCaching’s ?

In general yes, I may come up with a new ICloner abstraction or similar, and then different implementations may be created.
If provided, that will be used with Auto-Clone, otherwise a serializer will be needed.
This would technically work.

BUT.

There are limitations to that approach (see here, "Limitation") and some caveats:

In general, serializers allow you to go above and beyond that, with things like support to deserialize interfaces and stuff like that (I've used that in the past).

Also, more generally, adding another abstraction/concept I'm not sure would be the best thing to do.
I need some time to think about it.

I think this could bring FusionCache many benefits, especially for scenarios where object immutability is important but performance is still critical.

Fair point.

Thanks again for your work. I will wait your thoughts :)

Thanks for sharing your thoughts, always good to get to know new perspectives!

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Performance difference when enabling auto-clone vs EasyCaching.InMemory #531

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Performance difference when enabling auto-clone vs EasyCaching.InMemory #531

Uh oh!

gioce90 Sep 2, 2025

Replies: 1 comment

Uh oh!

jodydonetti Sep 5, 2025 Maintainer

gioce90
Sep 2, 2025

jodydonetti
Sep 5, 2025
Maintainer