Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of cdoronc@gmail.com designates
 74.125.82.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=KyyPd/7PYHshU/GjxsCEbZsTROoy29cPTBH4uWcHFbRERoHBQhi8mJ4daJyl0o2EB3
         zJMEq/SUhvrYlil8kYG8rP0zgjk0SAHK5zqbvWUCjYAS+1dKT5jm5oCQ8x7kRb5CGNtA
         t3YZua+yfmBHAKuXATXjYORF0bwCxlW4m69s8=
MIME-Version: 1.0
In-Reply-To: <AANLkTilA82p6XUO9bY-CCZb5h4u-4Z8_9Pp9iYD4r4y-@mail.gmail.com>
References: <AANLkTinIHwqvxv-Jy7G-4nm0umXuBLCHSQ3Z-bH7jQgC@mail.gmail.com>
	<AANLkTinCpcj-CCwfUptBUGwR-fdNHyGRcWzSMk71Qh1l@mail.gmail.com>
	<AANLkTikXjxt4scoT7eoO74sUkvPC6jEYj1H7_Vgs3qgo@mail.gmail.com>
	<AANLkTim45o9H5QKNtnGJCTufIFqN-3-Mv81IdWDcq7YY@mail.gmail.com>
	<AANLkTilb21p7kOdnlDsqLC_Qtb8q9snOjS82_KLgTJDy@mail.gmail.com>
	<AANLkTinMAZw31ixegF2TcRR6hpENbi5ZKbTSdfnJMwv5@mail.gmail.com>
	<AANLkTinz0iRJYCnBIkMU-wY4AF-qPMhcG9jmP63P938S@mail.gmail.com>
	<AANLkTilX0ciOcorCvAyxphC83N9MqxhVxhtjC6DLKYiE@mail.gmail.com>
	<AANLkTimiydS-MA6Hk-t0DWDY3aPfPdZoLtDSXaPdtfNo@mail.gmail.com>
	<AANLkTilYax03jtMbztldyyRQrr0LhsrZPcXXItgeXoIq@mail.gmail.com>
	<AANLkTikYfifeAkHNZ_yUtWxP2Q4RMmFFOp5OdlDUazWX@mail.gmail.com>
	<AANLkTimbotk3Q09BUalUEfAkp5x19xPmeDotvt0ucQgc@mail.gmail.com>
	<AANLkTimy6Qww9nEiXnKIsHrw0vgOK0mQOv8V6W5w3zEp@mail.gmail.com>
	<AANLkTimwPXTlUIm9Yjv6YjNNedKn249aKTo8dsoQzIEY@mail.gmail.com>
	<AANLkTinzcxPN7ynFvFnkTyqqmdvarf5hSXdp9icIqp6Y@mail.gmail.com>
	<AANLkTilA82p6XUO9bY-CCZb5h4u-4Z8_9Pp9iYD4r4y-@mail.gmail.com>
Date: Wed, 9 Jun 2010 14:39:17 +0300
Message-ID: <AANLkTikQJSRWydCQTbNMbFLH28V0XK0oltS128F-JweF@mail.gmail.com>
Subject: Re: Proposal: Scorer api change
From: Doron Cohen <cdoronc@gmail.com>
To: dev@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016368334d220e7780488975b7a

--0016368334d220e7780488975b7a
Content-Type: text/plain; charset=ISO-8859-1

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

--0016368334d220e7780488975b7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;">
If you can fix a hotspot in Lucene to avoid an extra method call, an<br>
extra add/multiply, etc., you should. =A0Doing so ensures the cost can&#39;=
t<br>
be there. =A0Not doing so means you rely on the JRE to be smart enough,<br>
and it very easily may not be (there are so many variables), and that<br>
also makes Lucene&#39;s performance more fragile/env-specific.<br>
<br>
Why take that chance?<br></blockquote><div><br>Of course, but also subject =
to considerations of code readability/maintainability/extendability/wrapabi=
lity.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0=
pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">

I also don&#39;t rely on benchmarks to validate this on a case-by-case<br>
basis; the cost for any single change (like this one) can easily be in<br>
the noise, yet these micro-costs do add up.<br>
<br>
Different rules apply &quot;down low&quot;. =A0It&#39;s like quantum physic=
s!<br></blockquote><div><br>I think you&#39;d still not modify a nicely ext=
endible/wrapable API=20
just to avoid the extra call, unless benchmarking shows that the cost is hi=
gh.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt=
 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


I think, besides avoiding method calls, there are compelling reasons<br>
to consider a stronger decoupling of matching &amp; scoring. =A0A Query<br>
really ought to be two separable things -- matching (like Filter) and<br>
scoring.<br></blockquote><div><br>Agree, this would be nice. (Though it wou=
ld not help John with the requirement to score arbitrary docs). <br><br>Dor=
on</div></div><br></div>

--0016368334d220e7780488975b7a--