> > 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
