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

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

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.

As setting pos takes time that will not be required in the real code, it introduces an error in the benchmark results.

But pos is actually needed in real code in this case, as proven in strange behavior of grep with global match [resolved], isn't it?

Then we are back to the possibility that time to initialize obscures the differences in the code under test.

It seems that Benchmark isn't fit for the job, you may need a profiler to mark where you want to start and end mesuring. I have little experience in profilers, so I can't suggest anything at the moment.