[
https://issues.apache.org/jira/browse/SOLR-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935967#comment-16935967
]
Andrzej Bialecki commented on SOLR-8241:
-----------------------------------------
Updated patch with an extended benchmark in {{TestFastLRUCache}}. I attached
the full results of the benchmark (rather puzzling) but here are some
highlights:
* LRUCache is on average the weakest contender, being usually the slowest and
with the lowest hit ratio.
* Caffeine cache is not a clear winner, though - I'd say on average it's on
par with FastLRUCache, both when it comes to speed and hit ratio.
* its detailed behavior differs from that of LRUCache and FastLRUCache in
specific test scenarios, sometimes greatly, but I couldn't figure out a
consistent pattern or a trend where Caffeine would consistently outperform
FastLRUCache. Based on these results I can't clearly recommend Caffeine over
FastLRUCache for a specific scenario (eg. "as the number of threads grows, you
should use ...", or "for larger caches you should use...", or "for fast caching
you should use ...").
I tried running JMH benchmarks in Caffeine but after struggling with build
issues ([#350|https://github.com/ben-manes/caffeine/issues/350]) I gave up for
now.
> Evaluate W-TinyLfu cache
> ------------------------
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Ben Manes
> Assignee: Andrzej Bialecki
> Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-8241.patch, SOLR-8241.patch, SOLR-8241.patch,
> SOLR-8241.patch, SOLR-8241.patch, caffeine-benchmark.txt, proposal.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1).
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset
> by the slower performance of the implementation. An original goal appeared to
> be to introduce ARC, a patented algorithm that uses ghost entries to retain
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It
> uses a frequency sketch to compactly estimate an entry's popularity. It uses
> LRU to capture recency and operate in O(1) time. When using available
> academic traces the policy provides a near optimal hit rate regardless of the
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a
> dependency on. But, the code is fairly straightforward and a port into Solr's
> caches instead is a pragmatic alternative. More interesting is what the
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
