in reply to Memory efficiency, anonymous vs named's vs local subroutines

Anonymous subs are cheaper in terms of usage (invoking a named sub includes a round-trip to the symbol table) and memory.

Named subs:

use strict; use warnings;
my $begin;
BEGIN { chop( $begin = `ps -o vsz= $$` )}

eval "sub F_$_ {
    my( \$a, \$b, \$c ) = \@_; 
    my \$x = $_; 
    return \$a * \$b - (\$x + \$c); 
}" for 1..1e4;

END {
    chop( my $end = `ps -o vsz= $$` );
    print "$end - $begin = ",$end - $begin, "\n";
}
__END__
60924 -  22228 = 38696

[download]

Anonymous subs:

use strict; use warnings;
my $begin;
BEGIN { chop( $begin = `ps -o vsz= $$` )}
my @ary;
$ary[$_] = eval "sub {
    my( \$a, \$b, \$c ) = \@_; 
    my \$x = $_; 
    return \$a * \$b - (\$x + \$c); 
}" for 1..1e4;

END {
    chop( my $end = `ps -o vsz= $$` );
    print "$end - $begin = ",$end - $begin, "\n";
}
__END__
53356 -  22228 = 31128

[download]

That makes ca. 3.1kB per anonsub, 3.9 per named sub. Slightly different numbers than BrowserUk's above, but also slightly different architecture and version of perl:

perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi

update: The ca. 750 extra bytes for named subs may well be just the cost of allocating a GLOB for the subroutine in the symbol table, which comes wiith SCALAR, HASH, ARRAY, CODE and FILEHANDLE slots. Currently I don't recall whether they are autovivified as needed or allocated in one go.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^2: Memory efficiency, anonymous vs named's vs local subroutines
by BrowserUk (Patriarch) on Jul 18, 2015 at 18:14 UTC
    The ca. 750 extra bytes for named subs may well be just the cost of allocating a GLOB for the subroutine in the symbol table,

    Running the code below to create a million STASH aliases to a single sub:

    sub F123456{  my( $a, $b, $c )= @_; my $x = 123456; return $a * $b - $
+c; };;
*{"X$_"} = \&F123456 for 0 .. 1e6;;

    [download]

    results in an increase in the process size of almost exactly 300MB, thus 300 bytes per STASH entry.

    Some of the extra space may be down to unreused (but reusable) space allocated and freed during the doubling of the STASH hash as it grows. I can't think of any way to isolate that.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
    I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]
[d/l]
      Some of the extra space may be down to unreused (but reusable) space allocated and freed during the doubling of the STASH hash as it grows.

      Devel::Peek shows that stash entries created by coderef assignment to a GLOB are missing the MAGIC part of a GV: 

      use Devel::Peek;
sub foo {
    print "in foo\n";
}
*bar = \&foo;
print "----\nfoo:\n----\n";
Dump(*foo);
print "----\nbar\n----\n";
Dump(*bar);
__END__
----
foo:
----
SV = PVGV(0x1765790) at 0x1731550
  REFCNT = 3
  FLAGS = (RMG,MULTI,IN_PAD)
  MAGIC = 0x1732e80
    MG_VIRTUAL = &PL_vtbl_backref
    MG_TYPE = PERL_MAGIC_backref(<)
    MG_OBJ = 0x1725238
  NAME = "foo"
  NAMELEN = 3
  GvSTASH = 0x1705800   "main"
  GP = 0x1732870
    SV = 0x0
    REFCNT = 1
    IO = 0x0
    FORM = 0x0  
    AV = 0x0
    HV = 0x0
    CV = 0x1725238
    CVGEN = 0x0
    LINE = 4
    FILE = "f.pl"
    FLAGS = 0xa
    EGV = 0x1731550     "foo"
----
bar
----
SV = PVGV(0x17657c0) at 0x1725208
  REFCNT = 3
  FLAGS = (MULTI,ASSUMECV,IN_PAD)
  NAME = "bar"
  NAMELEN = 3
  GvSTASH = 0x1705800   "main"
  GP = 0x1759a40
    SV = 0x0
    REFCNT = 1
    IO = 0x0
    FORM = 0x0  
    AV = 0x0
    HV = 0x0
    CV = 0x1725238
    CVGEN = 0x0
    LINE = 5
    FILE = "f.pl"
    FLAGS = 0xe
    EGV = 0x1725208     "bar"

      [download]

      I don't think the sizes reported by Devel::Size are accurate since the stash entry created by coderef assignment is reported as being bigger.
      Go figure.

      use Devel::Size qw(size total_size);
sub foo {
    print "in foo\n";
}
print "size foo: ",size(*foo),"\n";
print "total_size foo: ",total_size(*foo),"\n";
print "size bar: ",size(*bar),"\n";
print "total_size bar: ",total_size(*bar),"\n";
print "difference: ",size(*foo) - size(*bar),"\n";
__END__
size foo: 7034
total_size foo: 7034
size bar: 7186
total_size bar: 7186
difference: -152

      [download]
      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom