lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eks dev <>
Subject Re: DisjunctionSumScorer small tweak maybe?
Date Mon, 21 Jan 2008 16:48:27 GMT
I have created Jira issue with this, 

The only question for me here is if this policy of "do not touch disk in Scorer constructor"
should stay.  Actually an IOException that gets thrown in this case does not propagate too
far, ends up already in BooleanScorer2.   

Performance gain is not impressive, by no means, well under 1%, as expected. in spite of that
worth committing as it is often a lot of small changes that bring some speed-up, rather than
having one killer "turbo" patch on such a dense code :)

----- Original Message ----
From: Paul Elschot <>
Sent: Friday, 18 January, 2008 4:57:18 PM
Subject: Re: DisjunctionSumScorer small tweak maybe?

On Friday 18 January 2008 14:48:21 eks dev wrote:
> would it be possible(I see no reason why not, but ...) to move
 ScorerDocQueue initialization into constructor, instead of :
>     if (scorerDocQueue == null) {
>       initScorerDocQueue();
>     }
> in next() and skipTo() methods? 

That is quite possible. I did not put this initialisation
in the constructor to avoid calling next() and/or skipTo()
on the subscorers during construction.

The reason for that is that most (perhaps even all) other
Scorer constructors at the time did the same thing, probably
to avoid going to the disk for the posting lists, and possibly
for the proximity info, before actually starting the search
for the query.

At the time there was no benchmark available to test
whether this helps performance so I left it at that,
even though I still don't really like the code you showed

I have not looked at contrib/benchmark yet,
could that provide a way to test this?

Paul Elschot

To unsubscribe, e-mail:
For additional commands, e-mail:

Sent from Yahoo! Mail - a smarter inbox

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message