From 5247d03dd8125594173a7d27bc27bcc08b01b7b1 Mon Sep 17 00:00:00 2001 From: David Mitchell Date: Wed, 7 Dec 2016 14:48:50 +0000 Subject: [PATCH] t/perf/benchmarks: tweak cachegrind explanation I pushed the previous commit before remembering to proofread what I wrote. --- t/perf/benchmarks | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/t/perf/benchmarks b/t/perf/benchmarks index d00cfa3..5526f8e 100644 --- a/t/perf/benchmarks +++ b/t/perf/benchmarks @@ -67,17 +67,23 @@ # for my $__loop__ (1..$ARGV[0]) { # 1; # } +# # and as above, but with the '1;' in the loop body replaced with: +# # CODE; # # It then pipes each of the two sources into +# # PERL_HASH_SEED=0 valgrind [options] someperl [options] - N -# where N is set to 10 and then 20, -# then uses the result of those four runs to subtract out the perl startup -# and loop overhead. So only what's in SETUP and CODE can affect the -# benchmark, and if the loop leaves state changed (such as storing a value -# in a hash), then the benchmark result of running CODE with the -# hash populated. +# +# where N is set to 10 and then 20. +# +# It then uses the result of those four cachegrind runs to subtract out +# the perl startup and loop overheads. So only what's in SETUP and CODE +# can affect the benchmark, and if the loop happens to leave some state +# changed (such as storing a value in a hash), then the final benchmark +# timing is the result of running CODE with the hash entry populated +# rather than empty. [ -- 1.8.3.1