Number of significant digits in @btime seems to be an overkill

[rafael-guerra-www]

Running @btime multiple times, three of them shown below, outputs:
281.849 ns (7 allocations: 176 bytes)
279.452 ns (7 allocations: 176 bytes)
282.479 ns (7 allocations: 176 bytes)

The observed variability in the results suggests that printing 6 digits is non-sense (let alone in this case going to 1/1000 of nanosecond precision).
Suggest that printing only 3 significant digits should be enough:
282 ns (7 allocs: 176 bytes)
279 ns (7 allocs: 176 bytes)
282 ns (7 allocs: 176 bytes)

This issue is independent of the units printed (μs, ms, etc)

[mcabbott]

I think the logic of printing 3 digits is that the prefixes are separated by 3, so if you have some μs and some ms, it's easier to compare. Not sure how much it matters -- could try a PR changing it (to say 3 digits total) and see how it looks?

julia> let N = 1000
         x = randn(N); y = randn(N);
         @btime dot($x, $y)
         @btime sum($x .* $y)
       end;
  min 658.385 ns, mean 662.622 ns (0 allocations)
  min 688.061 ns, mean 1.291 μs (1 allocation, 7.94 KiB)

Edit, all 3 figures:

  min 658 ns, mean 662 ns (0 allocations)
  min 688 ns, mean 1.29 μs (1 allocation, 7.94 KiB)

[rafael-guerra-www]

The logic you mention is indeed useful, even if not all the digits printed are significant.
On this basis, it would probably be better to keep the 3 decimal digits as they are, except for the nanoseconds case?

[mcabbott]

Whole numbers for ns doesn't seem crazy.

Could investigate something like 2.479 μs, 82.47- μs, 282.4-- μs, maybe too weird? Just rounding to a fixed number of significant figures might also be OK, like 2.470 μs, 82.400 μs, 282.000 μs? Not sure.

[gdalle]

Closing this in favor of #125 and the discussion therein