[ https://issues.apache.org/jira/browse/LUCENE-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084281#comment-16084281 ]
Michael McCandless commented on LUCENE-7905: -------------------------------------------- bq. Its a bit tricky to see the diffs since the file got moved too, but basically it just replaces MultiTermsEnum with a standard PQ? That's it, except I also changed: {noformat} while (segmentOrds[segmentIndex] <= segmentOrd) { ordDeltaBits[segmentIndex] |= delta; ordDeltas[segmentIndex].add(delta); segmentOrds[segmentIndex]++; } {noformat} to: {noformat} assert segmentOrds[segmentIndex] <= segmentOrd; do { ordDeltas[segmentIndex].add(delta); segmentOrds[segmentIndex]++; } while (segmentOrds[segmentIndex] <= segmentOrd); {noformat} Which should make the branch easier to predict (since the loop will always run the first time), but maybe the effect is negligible. I think likely the cost we're saving from MTE is its {{TermMergeQueue.fillTop}} method? It's doing a lot of work, sort of recursing into the PQ, with a if inside a for inside a while, to find all subs on the current term, and then it has to do {{pushTop}} after that. In general MTE is not allowed to .next() the subs because it doesn't know if the caller will ask for postings on this term. [~rcmuir] suggested we could maybe make pullTop()/pushTop() lazy which is a neat idea... > Optimizations for OrdinalMap > ---------------------------- > > Key: LUCENE-7905 > URL: https://issues.apache.org/jira/browse/LUCENE-7905 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Michael McCandless > Assignee: Michael McCandless > Fix For: 7.1 > > Attachments: LUCENE-7905.patch > > > {{OrdinalMap}} is a useful class to quickly map per-segment ordinals to > global space, but it's fairly costly to build, which must typically be done > on every NRT refresh. > I'm using it quite heavily in two different places, one for > {{SortedSetDocValuesFacetCounts}}, and another custom usage, and I found some > small optimizations to improve its construction time. > I switched it to use a simple priority queue to merge the terms instead of > the more general {{MultiTermsEnum}}, which does extra work since it must also > provide postings, implement seekExact, etc. > I also pulled {{OrdinalMap}} out into its own oal.index class. > When testing construction time for my case the patch is ~16% faster (159.9s > -> 134.2s) in one case with 91.4 M terms and ~9% faster (115.6s -> 105.7s) in > another case with 26.6 M terms. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org