core.cache sessions may have a performance impact

[yogthos]

This thread indicates that core.cache may be causing a significant performance hit. Might be worth investigating.

[boechat107]

Thanks, @yogthos. I'll use criterium to generate some benchmarks. Perhaps I should have taken this as a very serious warning. I'll investigate it better.

[boechat107]

I have created a namespace for performance comparison with the ring's default in-memory implementation. In summary, in the current version (0.1.1) read operations are ~40 times slower; write operations, ~300 times slower.

Looking at core.cache's code and running the VisualVM's profiler, I guess that it's possible to improve the performance by doing some small changes. I'm planning to do it very soon.

Anyway, of course that we should expect some overhead for the TTL session when comparing to the ring's default in-memory implementation.

[yogthos]

Yeah, I think some overhead is definitely to be expected, but would be nice if it could be within an order of magnitude at least. :) Otherwise, running a thread to do session cleanup is probably cheaper overall.

[yogthos]

Another idea might be to compare performance using Java cache libs like Guava cache.

[yogthos]

I made a project wrapping expiringmap Java lib here. It should be trivial to swap in for core.cache and see if it performs better.

[boechat107]

Thanks, @yogthos! I'll compare the performance using your lib today.

I agree with you. In the worst case, providing an implementation that uses an additional thread for session cleanup could be a good alternative.

[boechat107]

By my last tests, expiring-map can be at most ~2x slower than the bare in-memory store in the worst case, which is a huge improvement over core.cache.

expiring-map became the default implementation.