Re^2: RFC extending Benchmark.pm to facilitate CODEHASHREF

[LanX]

> 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

{ 
  name1 => sub {

          },
  name2  => sub {

          },
}

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

sub do_something { 
  # not fast enough
}

then called

sub do_something_old {
  ...
}

or

sub do_something_1 {
  ...
}

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.

[BrowserUk]

Which is Kenosis code, not the code I wrote. (playing tricks again you funny little bastard ... yawn)

As clearly identified in the post to which I linked, (so no "trick"). Instead you write crap like this.

[LanX]

> Instead you write crap like this.

Again resorting to vulgarities when your tricks fail?