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.