You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2014/01/14 11:46:55 UTC

[jira] [Updated] (LUCENE-5399) PagingFieldCollector is very slow with String fields

     [ https://issues.apache.org/jira/browse/LUCENE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Muir updated LUCENE-5399:
--------------------------------

    Attachment: LUCENE-5399.patch

here's my patch (the hack version).

I found this because solr's searchAfter integration (SOLR-5463) requires a sort on the unique key, so basically that means its tripping this worst case.

> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org