[
https://issues.apache.org/jira/browse/LUCENE-7299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300949#comment-15300949
]
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 it.
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: https://issues.apache.org/jira/browse/LUCENE-7299
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: ByteBlockListSorter.java, 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
