[
https://issues.apache.org/jira/browse/LUCENE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17475529#comment-17475529
]
Greg Miller commented on LUCENE-10374:
--------------------------------------
OK, here's a thought: LUCENE-10350 actually does three things at once (or two
depending on how you're counting).
# Access the dense {{values}} array directly for counting instead of checking
whether-or-not it's null every time it needs to increment a count.
# Moves the check for whether-or-not {{liveDocs}} is null outside of the loop,
and
# Goes from using a for-loop to a while-loop since the docId is no longer
needed inside the loop for checking against {{liveDocs}} if it's null (it
retains the for-loop in the case that it needs to check {{liveDocs}}
I wonder if there's some optimization that's no longer taking place in some
setups (JVM, hardware?) related to 2/3? Maybe there's some sort of loop
optimization going on? The idea behind 1 seems so straight-forward that I
really can't imagine it causing a regression, but who knows.
So I'm going to open new issues for 1 and 2/3 and try pushing those changes
independently to see if we can narrow things down further.
> Track down the "browse" taxonomy faceting qps regression
> --------------------------------------------------------
>
> Key: LUCENE-10374
> URL: https://issues.apache.org/jira/browse/LUCENE-10374
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Greg Miller
> Priority: Major
>
> We need to track down the source of the regression observed here:
> [https://home.apache.org/~mikemccand/lucenebench/2022.01.10.18.03.12.html.]
> Some details on the regression hunting are in
> [https://github.com/apache/lucene/pull/597.]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
