[
https://issues.apache.org/jira/browse/LUCENE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-5399:
---------------------------------------
Attachment: LUCENE-5399.patch
Good catch Rob; I like your solution.
It's crazy we have this code dup (the duplicate, I think out of date, copy
of TermOrdValComparator in Solr) ... I think we should refactor here
and fix Solr to use Lucene's improved version. You shouldn't have to
fix issues like this in N places.
So I started from your patch, and got missing last/first support
working in Lucene ... but I haven't dedup'd Solr's copy yet.
I also want to try reversing the "check bottom" and "check top" in
PagingFieldCollector; I think that might give some speedups too.
> PagingFieldCollector is very slow with String fields
> ----------------------------------------------------
>
> Key: LUCENE-5399
> URL: https://issues.apache.org/jira/browse/LUCENE-5399
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
> Reporter: Robert Muir
> Attachments: LUCENE-5399.patch, LUCENE-5399.patch
>
>
> PagingFieldCollector (sort comparator) is significantly slower with string
> fields, because of how its "seen on a previous page" works: it calls
> compareDocToValue(int doc, T t) first to check this. (its the only user of
> this method)
> This is very slow with String, because no ordinals are used. so each document
> must lookup ord, then lookup bytes, then compare bytes.
> I think maybe we should replace this method with an 'after' slot, and just
> have compareDocToAfter or something.
> Otherwise we could use a hack-patch like the one i will upload (i did this
> just to test the performance, although tests do pass).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
