You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by "Marvin Humphrey (JIRA)" <ji...@apache.org> on 2010/06/19 02:43:22 UTC

[jira] Resolved: (LUCY-113) ORMatcher and ORScorer

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

Marvin Humphrey resolved LUCY-113.
----------------------------------

    Resolution: Fixed

Committed as r956163.

> ORMatcher and ORScorer
> ----------------------
>
>                 Key: LUCY-113
>                 URL: https://issues.apache.org/jira/browse/LUCY-113
>             Project: Lucy
>          Issue Type: New Feature
>          Components: Core - Search
>            Reporter: Marvin Humphrey
>            Assignee: Marvin Humphrey
>         Attachments: or_matcher.patch
>
>
> ORMatcher and and its scoring companion ORScorer are based on Lucene's
> DisjunctionSumScorer.  They use a priority queue to channel sub-matchers and
> proceed doc-at-a-time.  
> This priority queue is a serious search-time bottlneck and a lot of work has
> gone into optimizing the algorithm.  As in Lucene, we have inlined the
> priority queue and removed as much indirection and function-call overhead as
> possible.  However, in Lucene, ScorerDocQueue is a separate class, while here
> everything is achieved with static functions so that the C compiler may make
> maximum optimizations.
> ORMatcher is separated from ORScorer as an optimization; during Next(),
> ORScorer accumulates scores from subscorers which match, while ORMatcher's
> Next() method skips this work and avoids the overhead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.