code review 9837049: testing: quantize AllocsPerRun

testing: quantize AllocsPerRun
As the code now says:

We are forced to return a float64 because the API is silly, but do
the division as integers so we can ask if AllocsPerRun()==1
instead of AllocsPerRun()<2.

[r, 2013-05-30 15:11:39]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[rsc, 2013-05-30 15:20:49]

LGTM

[rsc, 2013-05-30 15:21:04]

Please update the doc comment to note that the values returned are integers.

[r, 2013-05-30 15:28:11]

*** Submitted as https://code.google.com/p/go/source/detail?r=322bd4cbe91e ***

testing: quantize AllocsPerRun
As the code now says:

We are forced to return a float64 because the API is silly, but do
the division as integers so we can ask if AllocsPerRun()==1
instead of AllocsPerRun()<2.

R=golang-dev, rsc
CC=golang-dev
https://codereview.appspot.com/9837049

[kevlar, 2013-12-09 10:55:28]

On 2013/05/30 15:28:11, r wrote:
> *** Submitted as https://code.google.com/p/go/source/detail?r=322bd4cbe91e ***
> 
> testing: quantize AllocsPerRun
> As the code now says:
> 
> We are forced to return a float64 because the API is silly, but do
> the division as integers so we can ask if AllocsPerRun()==1
> instead of AllocsPerRun()<2.
> 
> R=golang-dev, rsc
> CC=golang-dev
> https://codereview.appspot.com/9837049

I just noticed that the semantics of AllocsPerRun were changed to return whole
numbers only.  Can you explain the rationale here?  I think the clarity of the
test is impaired if, despite an assertion that AllocsPerRun == 1, it could be
almost but not quite 2 and still pass the unit test.  To me, saying AllocsPerRun
< 2 conveys exactly what the conditional is testing, and makes it clear under
what circumstances the check will fail.  It also seems strange to make a test
fail if it is improved (possibly on a particular platform where it can be
optimized) from 2 AllocsPerRun to 1.  Perhaps things have changed, but when I
initially created this API, its uses in the stdlib were not all set precisely at
their present value, and seemed to be there mostly to prevent regression.

[rsc, 2013-12-09 12:58:06]

The problem is that amortized background work means that if you do 100 runs
you might end up with 1.01 allocs per run, failing the == 1 test.

The goal is to count allocations that happen every time the function is
called. Those contribute to the integer part. The goal is to NOT count
allocations that only happen sometimes.

You are arguing for different goals.

Russ