I think in this case the array creation and population makes significant influence on results.
Sure, but in the original case the benchmark is flawed: the test code is being executed many times, and after the first execution, the array @b has been emptied... (unlike the arrays for the other cases)
Code that modifies test input is notoriously tricky to benchmark.
I think in this case the array creation and population makes significant influence on results. Consider this
You missed the point. The shifting of elements from the array makes it empty after first iteration. But Benchmark makes thousands of iteration within 1 second. All of those iterations work with empty array, this explains why this approach appears to be "faster".
Which is logical, at last. Scandal of the century is averted, I stand corrected - the only thing I have to find out is why my tests on actual data consistently show shifting to be faster than for (@list). Not several orders of magnitude faster as it was in that faulty benchmark but considerably so. I believe I have to look for an error...