Re: Initializing iterations while benchmarking

[alexm]

I guess you can always setup your data outside the closures, just before the benchmark takes place, as in:

use strict;
use warnings;
use Benchmark;

my @strings = qw(exception:tex exception:mex asdf tex:exception:mex);

my @one = @strings;
my @two = @strings;
my @three = @strings;

Benchmark::cmpthese( -5, {
    'one' => sub { my @filtered = grep { /exception:(?!tex)/} @one; },
    'two' => sub { my @filtered = grep { /exception/ && !/tex/ } @two;
+ },
    'three' => sub { my @filtered = grep { /exception:/g && !/\Gtex/ }
+ @three; },
});

[ig]

Unfortunately this doesn't work. In the third subroutine, the /g match sets pos on the elements of @three and this is carried over from one iteration to the next, as in strange behavior of grep with global match [resolved].

[alexm]

Okay, but then you can reset pos in case three, as you already explained.

sub { my @filtered = grep { pos = 0; /exception:/g && !/\Gtex/ } @thre
+e; }

Is there something wrong with this? Aside from the overhead of resetting pos, of course.

[ig]

From a functional perspective this produces the correct result but from a performance perspective it may not. If in the actual code there is only one pass over the array then setting pos is not required. In such a case it is only required for the benchmark. As setting pos takes time that will not be required in the real code, it introduces an error in the benchmark results.

An interesting case is if I want to compare the times with and without pos being set, yet always with the same initial conditions, to learn how much impact setting pos has. This can't be determined without isolating the iterations from each other. Then we are back to the possibility that time to initialize obscures the differences in the code under test.

My apologies for being so fussy - it is not that I don't appreciate your suggestions. I am trying to measure the performance of particular code in isolation and with strictly controlled initial conditions.