in reply to RFC extending Benchmark.pm to facilitate CODEHASHREF
If you recognise a few realities, benchmarks get a lot easier and far more accurate:
- Perl is a dynamic language;
eval is a dishinguishing characteristic and a useful tool.
- Benchmarks are not production code;
Failure to adhere to any theoretical best practices or production code standards, does not prevent them from serving their purpose.
- The perl feature that allows the non-block forms of map & grep is very powerful.
- The benchmark module wraps the code(ref) supplied, in an extra layer of subroutine.
It does this in an attempt to allow it to subtract the overhead added by the benchmarking process, from the timing of the code being tested.
All of this good work is completely negated when:
- you write a benchmark that first wraps the code being tested, in a named subroutine;
- then wraps a call to that named subroutine, in an anonymous subroutine in order to pass a reference to the benchmark module.
(Have they never heard of the \&subname syntax?)
Thus, the timing produced by the module incorporate three levels of subroutine call, only one of which has been partially negated. This demonstrates the naivety of the author(s).
If you write the benchmark in 1064279 like this:
Not only do you avoid the three repetitions of which you complain, you also avoiding adding the overhead of three levels of function call to each piece of code being tested; and thus produce a far more accurate timing of the important code.
It is simple, clear, concise and DRY; and works *now*, just as it always has.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: RFC extending Benchmark.pm to facilitate CODEHASHREF
by LanX (Saint) on Nov 27, 2013 at 02:13 UTC | |
by BrowserUk (Patriarch) on Nov 27, 2013 at 02:25 UTC | |
by LanX (Saint) on Nov 27, 2013 at 02:48 UTC |