You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2007/04/10 19:50:30 UTC
Why ORScorer delayed init?
Greets,
In DisjunctionSumScorer, both skipTo() and next() invoke
initScorerDocQueue() on the first iteration. However, since all
subscorers are added en masse via the constructor instead of
individually via an add() method which does not exist for this class,
it would be possible to trigger initScorerDocQueue() at construction
time rather than defer it, slightly simplifying the inner loop methods.
Does the delay offer some advantage that I'm missing? It looks like
an artifact.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Why ORScorer delayed init?
Posted by Chris Hostetter <ho...@fucit.org>.
: I thought it would avoid accessing the index as much as
: possible before actually doing a search, but I did not
: verify whether that is important.
: In case it is not, any simplification is off course welcome.
conceptually: once Query.createWeight(Searcher) is called, the "Search"
has already begun hasn't it? ... if not then, at the very least when
Weight.scorer(IndexReader) is called i would imagine.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Why ORScorer delayed init?
Posted by Paul Elschot <pa...@xs4all.nl>.
On Tuesday 10 April 2007 20:24, Yonik Seeley wrote:
> On 4/10/07, Marvin Humphrey <ma...@rectangular.com> wrote:
> > In DisjunctionSumScorer, both skipTo() and next() invoke
> > initScorerDocQueue() on the first iteration. However, since all
> > subscorers are added en masse via the constructor instead of
> > individually via an add() method which does not exist for this class,
> > it would be possible to trigger initScorerDocQueue() at construction
> > time rather than defer it, slightly simplifying the inner loop methods.
>
> Yes, I think I made this change to one or two of the other scorers in the
past.
> It makes more sense to me to pass everything needed in the constructor
> and get rid of the firstTime checks in next() and skipTo()
I kept this method of initializing because it was present in some
other existing Scorers. I did not really like it at the time either.
I thought it would avoid accessing the index as much as
possible before actually doing a search, but I did not
verify whether that is important.
In case it is not, any simplification is off course welcome.
Regards,
Paul Elschot
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Why ORScorer delayed init?
Posted by Yonik Seeley <yo...@apache.org>.
On 4/10/07, Marvin Humphrey <ma...@rectangular.com> wrote:
> In DisjunctionSumScorer, both skipTo() and next() invoke
> initScorerDocQueue() on the first iteration. However, since all
> subscorers are added en masse via the constructor instead of
> individually via an add() method which does not exist for this class,
> it would be possible to trigger initScorerDocQueue() at construction
> time rather than defer it, slightly simplifying the inner loop methods.
Yes, I think I made this change to one or two of the other scorers in the past.
It makes more sense to me to pass everything needed in the constructor
and get rid of the firstTime checks in next() and skipTo()
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org