Perhaps Devel::Size isn't telling the whole story, but...

#!/usr/bin/env perl

use strict;
use warnings;
use Devel::Size qw(total_size);


my(@o, @h);

print "Total starting size for \@o: ", total_size(\@o), "\n";
print "Total starting size for \@h: ", total_size(\@h), "\n";

for (1..100000) {
    push @o, bless {}, 'Foo';
}

for (1..100000) {
    push @h, {};
}

print "Total ending size for \@o: ", total_size(\@o), "\n";
print "Total ending size for \@h: ", total_size(\@h), "\n";
[download]

This produces:

Total starting size for @o: 64
Total starting size for @h: 64
Total ending size for @o: 15246272
Total ending size for @h: 15246272
[download]

The fact that a hashref is blessed doesn't seem to have any bearing on the total memory consumption. If I use Devel::Peek to see inside a blessed hashref versus a hash, I see one field in the SV that changes: STASH = 0x25fc9d8 "Foo". (Of course, the address will be different on every run). The FLAGS change too, but I don't think that changes memory consumption:

#!/usr/bin/env perl

use strict;
use warnings;
use Devel::Peek;


my $o = bless {}, 'Foo';
my $o2 = bless {}, 'Foo';
my $h = {};

Dump($o);
Dump($o2);
Dump($h);
[download]

This produces:

SV = IV(0x1e03ee8) at 0x1e03ef8
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x1de0358
  SV = PVHV(0x1de5b70) at 0x1de0358
    REFCNT = 1
    FLAGS = (OBJECT,SHAREKEYS)
    STASH = 0x1dfa948    "Foo"
    ARRAY = 0x0
    KEYS = 0
    FILL = 0
    MAX = 7
SV = IV(0x1e03e40) at 0x1e03e50
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x1de0508
  SV = PVHV(0x1de60d0) at 0x1de0508
    REFCNT = 1
    FLAGS = (OBJECT,SHAREKEYS)
    STASH = 0x1dfa948    "Foo"
    ARRAY = 0x0
    KEYS = 0
    FILL = 0
    MAX = 7
SV = IV(0x1e03e58) at 0x1e03e68
  REFCNT = 1
  FLAGS = (ROK)
  RV = 0x1dfa990
  SV = PVHV(0x1de6130) at 0x1dfa990
    REFCNT = 1
    FLAGS = (SHAREKEYS)
    ARRAY = 0x0
    KEYS = 0
    FILL = 0
    MAX = 7
[download]

Possibly worth noting, the STASH value is the same for $o and $o2, so both instances of the object point to the same "Foo" stash, which is encouraging.

I know it's not your code, but if the code is getting memory pinched, and it's not related to a memory leak, another strategy may be to allow the objects to be serialized / deserialized quickly, and maintain an index for where to find their serializations. Is it really necessary to hold 100k+ in memory at once? If so, if the primary attribute of each object were just a path where the serialization of the remainder of the object's guts can be found, you might save space. Anyway, that's just a thought. There could be constraints preventing that approach.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.