>>... 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
>
it is hard to measure this, micro benchmarks... someone with built
disassembler like Yonik could probably make much better qualified guess :)
what I am hypothesizing is following:
can this be faster:
while(-1 != (doc=i.next()){ //next() returns doc number or sentinel at the end
//do something with doc
}
than this (what we have today):
while(i.next()){
doc = i.doc();
//do something with doc
}
theoretically, the first one is:
- one method call
- test on equality on int (in future probably long) and
- one assignment to the local variable
in second case:
- two method calls
- test on equality on boolean
- one assignment to the local variable
so the question to answer (from performance point of view) is if t(method call)
+ t(comparison on boolean) takes longer than t(comparison on int/long). I know,
"it depends", but the question is is it likely enogh to warrant effort?
By the way, how we want to proceed with "The Most Popular Bug Source" on these
iterators, "one off" due to calling doc() before calling next()/skipTo()... if
I remember well, someone smart (Doug or Paul) suggested that we assert these
cases... Before moving on with this, I would propose to do it, could save some
debugging ours. If we opt for this first option of iterators, we do not have
this problem, also, once you are at the end of iterator, you cannot get cached
doc() (we had one off at the end as well)
I do not know, just brain dumping
__________________________________________________________
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]
