[
https://issues.apache.org/jira/browse/LUCENE-10379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476216#comment-17476216
]
Greg Miller commented on LUCENE-10379:
--------------------------------------
Looks like this change worked! The performance improvement carried over into
the nightly benchmarks this time with no regressions (e.g.,
[https://home.apache.org/~mikemccand/lucenebench/BrowseMonthTaxoFacets.html).]
So I strongly suspect the issue before (in LUCENE-10350) was changing the
for-loop to a while-loop. I suspect the compiler is able to optimize the
for-loop construct on the nightly benchmark hardware in a way that it can't
with the while-loop (SIMD maybe?). I'm going to give this a try (created
LUCENE-10380 to track).
> Count directly into the values array in FastTaxonomyFacetCounts#countAl
> -----------------------------------------------------------------------
>
> Key: LUCENE-10379
> URL: https://issues.apache.org/jira/browse/LUCENE-10379
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Greg Miller
> Assignee: Greg Miller
> Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This breaks out one of the two optimizations proposed in LUCENE-10350. As
> part of trying to track down the regressions caused by LUCENE-10350, I
> propose we push just this one optimization independently (see LUCENE-10374).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
