[
https://issues.apache.org/jira/browse/LUCENE-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-6118:
---------------------------------
Attachment: LUCENE-6118.patch
It wouldn't work unfortunately, let's imagine the following example: you have
four keys A, B, C and D. Given their hash codes, A and B should go to slot 3
while C and D should go to slot 4. It is possible to have them store at the
following slots in the hash table:
{noformat}
slot | 3 | 4 | 5 | 6 |
key | A | C | B | D |
{noformat}
Now if we remove A, the end of the chain is D but its slot is 4 not 3 so we
cannot move it into slot 3. Instead, we need to move B in the slot of A and D
in the slot of B to come back to a consistent state:
{noformat}
slot | 3 | 4 | 5 | 6 |
key | B | C | D | ∅ |
{noformat}
But you're right that the algorithm is not optimal here... I updated the patch
with something better (and hopefully still readable?).
> Improve efficiency of the history structure for filter caching
> --------------------------------------------------------------
>
> Key: LUCENE-6118
> URL: https://issues.apache.org/jira/browse/LUCENE-6118
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-6118.patch, LUCENE-6118.patch
>
>
> The filter caching uses a ring buffer that tracks frequencies of the
> hashcodes of the most-recently used filters. However it is based on an
> ArrayDeque<Integer> and a HashMap<Integer> which keep on (un)wrapping ints.
> Since the data-structure is very simple, we could try to do something
> better...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
