there is also similar issue that changes initialization in next() and skipTo() in ConjuctionScorer: https://issues.apache.org/jira/browse/LUCENE-1146
in this case, Constructor already throws IOException, and speed-up is much biger, 3.5%-4% on dense Scorers ----- Original Message ---- From: eks dev <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Monday, 21 January, 2008 5:48:27 PM Subject: Re: DisjunctionSumScorer small tweak maybe? I have created Jira issue with this, [ https://issues.apache.org/jira/browse/LUCENE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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 <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org 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 above. I have not looked at contrib/benchmark yet, could that provide a way to test this? Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
