|Problems? Is your data what you think it is?|
> 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).
WOW really? Oh man, thank you for telling me!
Well, unfortunately I've never done this.
> If you write the benchmark in 1064279 like this:
Which is Kenosis code, not the code I wrote.
(playing tricks again you funny little bastard? Ha ha ha ... yawn)
The approach of hashes with
is well known. but it's sufficiently different to easily introduce errors.
Especially when copying existing code, things like comma-separation, indentation, positions of names, ... (see also Eily's comment).
Secondly and more importantly the need to benchmark often comes if code has already been written and experimenting starts with cloned forms of
And I don't think I'm alone, two other monks already asked about filtering some subs out of a package and/or ignoring imported subs.
Now if you don't like a convenience module to facilitate this kind of benchmarking, better don't use it.
( addicted to the Perl Programming Language)
In reply to Re^2: RFC extending Benchmark.pm to facilitate CODEHASHREF