Benchmark.t/.pm: deal with short times

The number of iterations to do on various tests was set at 3 or 10
in the first incarnation of the test file 13 years ago, and hasn't
changed since. In the meantime, CPUs have gotten faster. So bump the
iteration count to 100. This makes no appreciable difference to total wall
time for the test file on my newish x86_64 platform, but will hopefully
make tests less likely to be running within the noise of  a single 100Hz
clock tick.

In particular, the NetBSD smokes were quite frequently failing tests 127
and 128, due to the CPU taken to do an empty loop being greater than that
for a full loop, thus leading to negative apparent execution time.  This
was likely to be due to the first taking "1" clock tick and the second
taking "0" ticks. Although this is less likely to happen now that the
iterations has been increased, this commit also adds a check to
Benchmark.pm for a negative apparent execution time, and if detected,
prints a "too few iterations" warning and resets it to zero.

1 files changed, 10 insertions, 0 deletions

diff --git a/lib/Benchmark.pm b/lib/Benchmark.pm
index 1d272a7d33..90e54a66ee 100644
--- a/lib/Benchmark.pm
+++ b/lib/Benchmark.pm
@@ -904,6 +904,16 @@ sub timethis{
 
     $n = $forn if defined $forn;
 
+    if ($t->elapsed($style) < 0) {
+        # due to clock granularity and variable CPU speed and load,
+        # on quick code with a small number of loops, it's possible for
+        # the empty loop to appear to take longer than the real loop
+        # (e.g. 1 tick verses 0 ticks). This leads to a negative elapsed
+        # time. In this case, floor it at zero, to stop bizarre results.
+        print "            (warning: too few iterations for a reliable count)\n";
+        $t->[$_] = 0 for 1..4;
+    }
+
     # A conservative warning to spot very silly tests.
     # Don't assume that your benchmark is ok simply because
     # you don't get this warning!