You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Michael McCandless (Jira)" <ji...@apache.org> on 2021/08/24 20:05:00 UTC

[jira] [Commented] (LUCENE-10068) Switch to a "double barrel" HPPC cache for the taxonomy LRU cache

    [ https://issues.apache.org/jira/browse/LUCENE-10068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404030#comment-17404030 ] 

Michael McCandless commented on LUCENE-10068:
---------------------------------------------

Even though this "double" map caching approach (to approximate LRU strategy) is less RAM efficient, each of those maps should be more RAM efficient than what's used today ({{LinkedHashMap}} based) so I'm hopeful on balance it'd be more RAM and CPU efficient, maybe enabling us to increase the default cache limit count.

> Switch to a "double barrel" HPPC cache for the taxonomy LRU cache
> -----------------------------------------------------------------
>
>                 Key: LUCENE-10068
>                 URL: https://issues.apache.org/jira/browse/LUCENE-10068
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/facet
>    Affects Versions: 8.8.1
>            Reporter: Gautam Worah
>            Priority: Minor
>
> While working on an unrelated getBulkPath API [PR|https://github.com/apache/lucene/pull/179], [~mikemccand] and I came across a nice optimization that could be made to the taxonomy cache.
> The taxonomy cache today caches frequently used ordinals and their corresponding FacetLabels. It uses the existing LRUHashMap (backed by a LinkedList) class for its implementation.
> This implementation performs sub optimally when it has a large number of threads accessing it, and consumes a large amount of RAM.
> [~mikemccand] suggested the idea of a two array backed HPPC int->FacetLabel cache. The basic idea behind the cache being:
>  # We use two hashmaps primary and secondary.
>  # In case of a cache miss in the primary and a cache hit in the secondary, we add the key to the primary map as well.
>  # In case of a cache miss in both the maps, we add it to the primary map.
>  # When we reach (make this check each time we insert?) a large number of elements in say the primary cache, (say larger than the existing {color:#871094}DEFAULT_CACHE_VALUE{color}=4000), we dump the secondary map and copy all the values of the primary map into it.
> The idea was originally explained in [this|https://github.com/apache/lucene/pull/179#discussion_r692907559] comment.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org