Re: ScorerDocQueue.HeapedScorerDoc
ok, I get it... imo it is worth trying
when we are already on this "method invocations" topic. Would it make sense to
change semantics of these iterators not to return boolen but rather document Id
with sentinel values.
This would definitely reduce number of method invocations by factor 2 at
least.--- {next() doc()} -> next()
It would be pretty easy to do that, just requires on one huge patch, but with
only simple changes ... this is public api (wait for V3.0?).
Would that make sense?
Also, without measuring I could not say if that would bring something, but
looks like.
I think MG4J people made this switch in last version as well.
- Original Message
> From: Paul Elschot <[EMAIL PROTECTED]>
> To: java-dev@lucene.apache.org
> Sent: Sunday, 27 July, 2008 1:04:26 AM
> Subject: Re: ScorerDocQueue.HeapedScorerDoc
>
> Op Saturday 26 July 2008 23:09:06 schreef eks dev:
> > what is the reason to have HeapedScorerDoc class in ScorerDocQueue?
> > Caching of the doc value?
>
> Yes. The underlying priority queue does log2(n) comparisons on them on
> some occasions.
>
> > Does this bring anything compared to
> > invoking doc() on Scorer, just curious, maybe I do not see something
> > ovious... If doc is the reason, I would bet on doc()
>
> Around 2005 it used to bring a bit of performance, but the latest JIT's
> don't seem to need such hand holding anymore. I'm considering to
> remove the cached queue size where the ScorerDocQueue is used,
> so I might as well try and remove this doc value caching.
>
> Regards,
> Paul Elschot
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
__
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at
Yahoo! http://uk.docs.yahoo.com/ymail/new.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-1345) Allow Filter as clause to BooleanQuery
[
https://issues.apache.org/jira/browse/LUCENE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eks Dev updated LUCENE-1345:
Attachment: DisjunctionDISI.patch
I just realised TestDisjunctionDISI had a bug (iterators have to be
reinitialized)...
apart from that only small change in DISIQueue to use constants instead of vars
(compiler should have done it as well, but you never know)
private final void downHeap() {
+int i = 1;
+int j = 2; //i << 1; // find smaller child
+int k = 3; //j + 1;
+
> Allow Filter as clause to BooleanQuery
> --
>
> Key: LUCENE-1345
> URL: https://issues.apache.org/jira/browse/LUCENE-1345
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: DisjunctionDISI.patch, DisjunctionDISI.patch,
> LUCENE-1345.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ScorerDocQueue.HeapedScorerDoc
Op Sunday 27 July 2008 11:04:01 schreef eks dev:
> ok, I get it... imo it is worth trying
>
> when we are already on this "method invocations" topic. Would it make
> sense to change semantics of these iterators not to return boolen but
> rather document Id with sentinel values. This would definitely reduce
> number of method invocations by factor 2 at least.--- {next() doc()}
> -> next()
>
> It would be pretty easy to do that, just requires on one huge patch,
> but with only simple changes ... this is public api (wait for V3.0?).
> Would that make sense?
>
> Also, without measuring I could not say if that would bring
> something, but looks like. I think MG4J people made this switch in
> last version as well.
I'm skeptical about this one, I think it will not be easy to beat
the simplicity of the current next()/skipTo()/doc(), especially
with good inlining.
But when it improves performance, I'm all ears.
Also, would sentinel testing keep its speed when doc numbers
change from int to long? I really don't know...
Regards,
Paul Elschot
>
>
>
>
>
> - Original Message
>
> > From: Paul Elschot <[EMAIL PROTECTED]>
> > To: java-dev@lucene.apache.org
> > Sent: Sunday, 27 July, 2008 1:04:26 AM
> > Subject: Re: ScorerDocQueue.HeapedScorerDoc
> >
> > Op Saturday 26 July 2008 23:09:06 schreef eks dev:
> > > what is the reason to have HeapedScorerDoc class in
> > > ScorerDocQueue? Caching of the doc value?
> >
> > Yes. The underlying priority queue does log2(n) comparisons on them
> > on some occasions.
> >
> > > Does this bring anything compared to
> > > invoking doc() on Scorer, just curious, maybe I do not see
> > > something ovious... If doc is the reason, I would bet on doc()
> >
> > Around 2005 it used to bring a bit of performance, but the latest
> > JIT's don't seem to need such hand holding anymore. I'm considering
> > to remove the cached queue size where the ScorerDocQueue is used,
> > so I might as well try and remove this doc value caching.
> >
> > Regards,
> > Paul Elschot
> >
> > ---
> >-- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> __
> Not happy with your email address?.
> Get the one you really want - millions of new email addresses
> available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
