lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrien Grand (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7299) BytesRefHash.sort() should use radix sort?
Date Wed, 25 May 2016 21:59:13 GMT


Adrien Grand commented on LUCENE-7299:

bq. That got me thinking, couldn't compare() do likewise?

compare() is not needed for radix sort so I think it is less confusing to have it only for
the introsort fallback?

bq. Or maybe reconsider if fewer is better or when we switch

In general abstractions tend to make things slower but in that case I think we are fine since
radix sort would still do most of the work. The cap on the recursion level does not aim at
keeping call stacks small but at switching to introsort when there are long common prefixes,
since introsort performed better in that case in my experiments. I will add a comment about

 bq. The Sorter.THRESHOLD constant confused me temporarily; perhaps "INSERTION_SORT_THRESHOLD"
would be less ambiguous in a class hierarchy of sorters with various thresholds.

+1 to rename

> BytesRefHash.sort() should use radix sort?
> ------------------------------------------
>                 Key: LUCENE-7299
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Minor
>             Fix For: 6.1, master (7.0)
>         Attachments:, LUCENE-7299.patch, LUCENE-7299.patch
> Switching DocIdSetBuilder to radix sort helped make things significantly faster. We should
be able to do the same with BytesRefHash.sort()?

This message was sent by Atlassian JIRA

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

View raw message