in reply to Re^2: Does "preallocating hash improve performance"? Or "using a hash slice"?
in thread Does "preallocating hash improve performance"? Or "using a hash slice"?

slicing does not seem to include the preallocation optimization

I don't know how you can say given that the test shows no benefit from pre-allocating[1].

But the reason the test shows no benefit from pre-allocating because the test is still flawed.

Lexical variables aren't freed when they go out of scope; they are kept around for use the next time the scope is entered. That means the hash is effectively pre-allocated for all tests![2].

$ perl -MDevel::Peek -e' sub x { my %h; Dump(%h, 0); keys(%h) = 100; Dump(%h, 0); } x() for 1..3; ' 2>&1 | grep MAX MAX = 7 MAX = 127 MAX = 127 <-- Preallocated even before C<< keys(%h) = 100; >>! MAX = 127 MAX = 127 <-- Preallocated even before C<< keys(%h) = 100; >>! MAX = 127

Adding undef %h; should provide better results.

$ perl -MDevel::Peek -e' sub x { my %h; Dump(%h, 0); keys(%h) = 100; Dump(%h, 0); undef %h; } x() for 1..3; ' 2>&1 | grep MAX MAX = 7 MAX = 127 MAX = 7 MAX = 127 MAX = 7 MAX = 127

  1. The number are far too small to be meaningful, and one would expect the difference to grow as the hash size increases. (1 vs 2: 3%, 4%, 4%, 6%; 3 vs 4: -3%, 5%, 3%, 4%)
  2. Well, except on the first pass of a given size of a given test.

Replies are listed 'Best First'.
Re^4: Does "preallocating hash improve performance"? Or "using a hash slice"?
by ikegami (Pope) on Feb 23, 2017 at 01:37 UTC
    On second thought, a fresh hash is created on scope exit because a reference to the hash is returned.
    $ perl -MDevel::Peek -e' sub x { my %h; Dump(%h, 0); keys(%h) = 100; Dump(%h, 0); return \%h; } x() for 1..3; ' 2>&1 | grep MAX MAX = 7 MAX = 127 MAX = 7 MAX = 127 MAX = 7 MAX = 127

    So all we have is a test that shows that @h{ @array } = @array; is faster than $h{ $_ } = $_ for @array;, but doesn't conclusively show any benefit from pre-allocating.