lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wang <>
Subject Re: Proposal: Scorer api change
Date Wed, 09 Jun 2010 15:16:46 GMT

    I hadn't considered the general implications of scoring arbitrary docs
until Earwin brought it up. I agree the can of warms it would open-up...

    Thoughts about:

     public float score(DocIdSetIterator iter);


    Just thinking out load.

    +++ on Query = Matcher + Scoring


On Wed, Jun 9, 2010 at 4:39 AM, Doron Cohen <> wrote:

> If you can fix a hotspot in Lucene to avoid an extra method call, an
>> extra add/multiply, etc., you should.  Doing so ensures the cost can't
>> be there.  Not doing so means you rely on the JRE to be smart enough,
>> and it very easily may not be (there are so many variables), and that
>> also makes Lucene's performance more fragile/env-specific.
>> Why take that chance?
> Of course, but also subject to considerations of code
> readability/maintainability/extendability/wrapability.
> I also don't rely on benchmarks to validate this on a case-by-case
>> basis; the cost for any single change (like this one) can easily be in
>> the noise, yet these micro-costs do add up.
>> Different rules apply "down low".  It's like quantum physics!
> I think you'd still not modify a nicely extendible/wrapable API just to
> avoid the extra call, unless benchmarking shows that the cost is high.
> I think, besides avoiding method calls, there are compelling reasons
>> to consider a stronger decoupling of matching & scoring.  A Query
>> really ought to be two separable things -- matching (like Filter) and
>> scoring.
> Agree, this would be nice. (Though it would not help John with the
> requirement to score arbitrary docs).
> Doron

View raw message