lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <cdor...@gmail.com>
Subject Re: Proposal: Scorer api change
Date Wed, 09 Jun 2010 11:39:17 GMT
>
> 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

Mime
View raw message