[
https://issues.apache.org/jira/browse/SOLR-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254671#comment-13254671
]
Shawn Heisey commented on SOLR-2889:
------------------------------------
After thinking about what ended up being the final code for SOLR-2906, I know
that I won't be able to tackle this, but I am wondering whether this is really
necessary any more. The timeDecay option on the LFU cache implementation could
be viewed as an LRU tweak to the LFU cache, which I think fulfills my original
goals even if it's not a true ARC cache. Does that mean this issue should be
closed? I can't say.
I hope someone really smart is able to provide some serious speed optimization
for the new LFU cache.
> Implement Adaptive Replacement Cache
> ------------------------------------
>
> Key: SOLR-2889
> URL: https://issues.apache.org/jira/browse/SOLR-2889
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 3.4
> Reporter: Shawn Heisey
> Priority: Minor
>
> Currently Solr's caches are LRU, which doesn't look at hitcount to decide
> which entries are most important. There is a method that takes both
> frequency and time of cache hits into account:
> http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache
> If it's feasible, this could be a good addition to Solr/Lucene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
