lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <ear...@gmail.com>
Subject Re: Proposal: Scorer api change
Date Wed, 09 Jun 2010 07:35:23 GMT
Lies, lies, lies :)
I mean, Sun JIT is overrelied on. Especially in regards to inlining.

But, there are some cases when you can trust it. I.e. if you call a
virtual method and this exact call-site gets refs to different objects
at runtime (meaning here - you wrap different Queries in your
WrapperQuery) - you can definetly rely on a call not being inlined.

So, I agree with John on his /rough/ overhead estimates, on the part
that it exists, and it's detectable. I don't agree on allowing
arbitrary doc scoring. People who really need this for some strange
applications, can emulate this now - by advancing() scorer to needed
doc, and calling score(). But for most people it's unnecessary, and as
I said - will lead to scaaary code.

If you really think that one or two method calls in a loop are
neglible, I ask you to join my holy crusade and erase
Scorer.score(Collector) set of methods :) they exist there for the
sole purporse of cutting on a few method calls, and are really,
really, really confusing.


2010/6/9 Shai Erera <serera@gmail.com>:
> I don't think the method call is an overhead John. You don't need to
> reiterate it. The compiler does make optimizations and inlines such
> code/calls if it can. More than that, the query processing involves so much
> method calls, that I do think that's insignificant.

Woohoo! Mexican standoff! :)

-- 
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message