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:

  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:

<Reveal this spoiler or all in this thread>

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.

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.

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

[reply]
[d/l]
[select]
      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.
[reply]
        > Instead you write crap like this.

        Again resorting to vulgarities when your tricks fail?

        Cheers Rolf

        ( addicted to the Perl Programming Language)

[reply]

In Section Meditations