lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7905) Optimizations for OrdinalMap
Date Wed, 12 Jul 2017 16:43:00 GMT


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:

          while (segmentOrds[segmentIndex] <= segmentOrd) {
            ordDeltaBits[segmentIndex] |= delta;


        assert segmentOrds[segmentIndex] <= segmentOrd;
        do {
        } while (segmentOrds[segmentIndex] <= segmentOrd);

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:
>             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
> 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,
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message