Re^3: Does "preallocating hash improve performance"? Or "using a hash slice"?

[ikegami]

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.

[ikegami]

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.