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:44:00 GMT


Michael McCandless commented on LUCENE-7905:

bq. Maybe we should also check how much better things would be with a specialized priority
queue too? As far as I remember, it helped a lot with disjunction scorers.

I like that idea!  I'll look at what we did there and see if it can work here.

bq. Maybe we should decouple OrdinalMap and MultiTermsEnum entirely and give OrdinalMap its
own TermsEnum+index wrapper?

+1, I'll do that.

> 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