If you recognise a few realities, benchmarks get a lot easier and far more accurate:

1. Perl is a dynamic language;

   eval is a dishinguishing characteristic and a useful tool.

2. 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.

3. The perl feature that allows the non-block forms of map & grep is very powerful.
4. 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.

> 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 {

          },
}
[download]

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
}
[download]

then called

sub do_something_old {
  ...
}
[download]

or

sub do_something_1 {
  ...
}
[download]

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.

Cheers Rolf

( addicted to the Perl Programming Language)

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.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

To get a lighter syntax you can already do something like :

my @arr_1 = map {rand 1e6} 8000;
my @arr_2 = map {rand 1e6} 6000;

my $cmp = {
  hash_values_diff => sub {
    my %diff3;
    @diff3{@arr_1} = @arr_1;
    delete @diff3{@arr_2};
    values %diff3 ;
  },
  
  using_vec => sub {
    my $vec = '';
    vec( $vec, $_, 1 ) = 1 for @arr_2;
    grep !vec( $vec, $_, 1 ), @arr_1;
  },

  hash_grep => sub {
    my %arr_2_hash;
    undef @arr_2_hash{@arr_2};
    grep !exists $arr_2_hash{$_}, @arr_1;
  }
};

cmpthese(-3, $cmp);
[download]

If you go for the package solution, you might as well have it use parent YourBenchmark, so that you can call CMP->benchmark(-5);. And you may want to add filtering of some sort, because one might want to call a function imported from another package inside of the functions that should be benchmarked. I'm sure someone could have come up with a function using something out of List::AllUtils for the exemple you gave. Edit: and you already said that with using the attributes as the tool for selecting the benchmarked subs, my bad.

Hi

Thanks for the input, pointing me to new use cases ! :)

I'm pretty sure it's possible to exclude imported subs.

And passing optional filter-conditions (like regex) operating on sub-names are a good idea.

Combined with optional attributes all cases should be covered.

Will show a proof of concept soon. : )

Cheers Rolf

( addicted to the Perl Programming Language)

use Attribute::Benchmark;

sub name1 :Benchmark { 
   ...
}

sub name2 :Benchmark { 
   ...
}
[download]

That is all.

So you liked the attribute idea? :)

 Attribute-Benchmark
=================== 
Created:      2013-11-26
[download]

"Publish or perish"? ;)

Cheers Rolf

( addicted to the Perl Programming Language)

To be honest, I can't remember reading that paragraph in your OP, though I may have skimmed it and absorbed it subconsciously.

I was also thinking along the lines of Test::Class::MOP's is testcase trait and how mop's method traits are basically a variation on sub attributes.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name