I think you are benchmarking something else than you said you are interested in. You said you have an array of some size and want to empty it somehow and later assign as many values as there were originally. And you're benchmarking creating a brand new array, assigning it some initial value and then assigning the values. That looks like a very different thing. Plus 100 is a fairly small number.

The attached benchmark suggests that it's best to just empty the array by assigning an empty list and if the number of elements is big, resize the array afterwards.

use Benchmark qw(cmpthese);

my $size = $ARGV[0] || 1000;

my @array = (1..$size);

sub undef_it {
    undef @array;
    $array[$_]=$_ foreach (0..$size-1);
    return;
}

sub empty_it {
    @array = ();
    $array[$_]=$_ foreach (0..$size-1);
    return;
}

sub empty_elements {
    undef $_ for @array;
    $array[$_]=$_ foreach (0..$size-1);
    return;
}

sub assign_list_of_undefs {
    @array = (undef) x $size;
    $array[$_]=$_ foreach (0..$size-1);
    return;
}

sub undef_resize {
    undef @array; $#array = $size;
    $array[$_]=$_ foreach (0..$size-1);
    return;
}

sub empty_resize {
    @array = (); $#array = $size;
    $array[$_]=$_ foreach (0..$size-1);
    return;
}

cmpthese( -10, {
    undef_it => \&undef_it,
    empty_it => \&empty_it,
    empty_elements => \&empty_elements,
    assign_list_of_undefs => \&assign_list_of_undefs,
    undef_resize => \&undef_resize,
    empty_resize => \&empty_resize,
});
[download]

BTW, the ()[0...100] doesn't seem to work the way you seem to expect it. It doesn't seem to generate a list of 101 undefs, rather it generates an empty list:

@a = ()[0..50];
print $#a;
[download]

It looks like your trying to benchmark preallocation, but you failed at doing that. The array already has at least 101 elements allocated before you attempt to initialize it. The array is not freed from pass to pass. That means you're basically benchmarking the fastest way to do nothing. Obviously, actually doing nothing ("my @working;") will be at least as fast as everything else.

"my @working = undef" doesn't make sense. It assigns one element to the array. Maybe you were thinking of "undef @working" which frees the internal buffer of the array?

It's curious that assign_length and x_with_value preallocate 100 elements then proceed to store 101 elements. Not that it matters, because the array already has at least 101 elements from the previous pass of the loop.

It's curious that your didn't test "$#working = 100;" to preallocate the array. Not that it matters, because the array already has at least 101 elements from the previous pass of the loop.

"my @working = ();" can be written as just "my @working;"

Thanks for the critique: I've updated my benchmarks with something hopefully a little better.

Yes, I was thinking of undef @working. Fixed.

I kept meaning to get those off-by-one errors matched up, but I knew it didn't actually make a difference... My bad.

$#working = 100; actually isn't part of what I was looking at: I was specifically looking at an array that (usually) already has a length.

my @working; is the same as my @working = (); when @working doesn't exist. Once it does, the latter does seem to actually clear the array. (As far as I can tell: My code that should throw errors if it didn't.)

my @working; is the same as my @working = (); when @working doesn't exist. Once it does, the latter does seem to actually clear the array.

Not all. It's already cleared (but not deallocated) at the end of the last pass by the run-time effect of my. my @working = (); will never result in something different than my @working;.

(my @working = () if $x; is not necessarily the same as my @working if $x;, but that code is a buggy to begin with.)

Are you confusing my @working; with just @working;? I noticed you removed the "my". Removing the "my" is silly. It's not something you should do. At least add this test, please:

    'my'            => 'my @working; $working[$_] = $_ foreach ( 0...1
+00 );',
[download]

If you want to benchmark explicitely clearing of the array, you should do that - and not start with a "new" array (although, behind the scenes, the array isn't quite new) each time. Move the declaration of the array outside of the loops. Something like:

our @working;
cmpthese -20, {
   one => '@working = (); $working[$_] = $_ foreach 0 .. 100',
   ...
};
[download]

Of course, if you're going to fill in all the elements anyway, why bother clearing them?

Mostly because I like the looks of it better. The difference in this case is immaterial. (One element.)

Maybe you shouldn't use ... as you seem to be thinking it behaves different from .., when it doesn't.

... is only different from .. in scalar context. (Or, if you want to be a doc lawyer, you could point out that perlop doesn't actually define the behaviour of ... in list context - but in such a case, you shouldn't use it either ;-))

The difference is not immaterial, it's non-existant. (the one-element difference is only when ... is used as the "range" flip-flop operator)
[]s, HTH, Massa (κς,πμ,πλ)