Re^3: 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
[download]

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

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%)
Well, except on the first pass of a given size of a given test.

Comment on Re^3: Does "preallocating hash improve performance"? Or "using a hash slice"? Select or Download Code

Replies are listed 'Best First'.
Re^4: Does "preallocating hash improve performance"? Or "using a hash slice"? by ikegami (Patriarch) 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` [download] 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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Does "preallocating hash improve performance"? Or "using a hash slice"?
by ikegami (Patriarch) on Feb 23, 2017 at 01:37 UTC

$ 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
[download]

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.

[reply]
[d/l]
[select]