4 use vars qw($VERSION @ISA @EXPORT @EXPORT_OK $AUTOLOAD %EXPORT_TAGS $warn);
9 @ISA = qw(Exporter DynaLoader);
11 # Items to export into callers namespace by default. Note: do not export
12 # names by default without a very good reason. Use EXPORT_OK instead.
13 # Do not simply export all your public functions/methods/constants.
15 # This allows declaration use Devel::Size ':all';
16 # If you do not need this, moving things directly into @EXPORT or @EXPORT_OK
18 %EXPORT_TAGS = ( 'all' => [ qw(
22 @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );
29 bootstrap Devel::Size $VERSION;
33 # Preloaded methods go here.
40 Devel::Size - Perl extension for finding the memory usage of Perl variables
44 use Devel::Size qw(size total_size);
46 my $size = size("A string");
48 my @foo = (1, 2, 3, 4, 5);
49 my $other_size = size(\@foo);
51 my $foo = {a => [1, 2, 3],
54 my $total_size = total_size($foo);
58 This module figures out the real sizes of Perl variables in bytes.
59 Call functions with a reference to the variable you want the size
60 of. If the variable is a plain scalar it returns the size of
61 the scalar. If the variable is a hash or an array, use a reference
68 The C<size> function returns the amount of memory the variable
69 returns. If the variable is a hash or an array, it only reports
70 the amount used by the structure, I<not> the contents.
72 =head2 total_size($ref)
74 The C<total_size> function will traverse the variable and look
75 at the sizes of contents. Any references contained in the variable
76 will also be followed, so this function can be used to get the
77 total size of a multidimensional data structure. At the moment
78 there is no way to get the size of an array or a hash and its
79 elements without using this function.
83 None but default, but optionally C<size> and C<total_size>.
85 =head1 UNDERSTANDING MEMORY ALLOCATION
87 Please note that the following discussion of memory allocation in perl
88 is based on the perl 5.8.0 sources. While this is generally
89 applicable to all versions of perl, some of the gory details are
90 omitted. It also makes some presumptions on how your system memory
91 allocator works so, while it will be generally correct, it may not
92 exactly reflect your system. (Generally the only issue is the size of
93 the constant values we'll talk about, not their existence)
97 It's important firtst to understand how your OS and libraries handle
98 memory. When the perl interpreter needs some memory, it asks the C
99 runtime library for it, using the C<malloc()> call. C<malloc> has one
100 parameter, the size of the memory allocation you want, and returns a
101 pointer to that memory. C<malloc> also makes sure that the pointer it
102 returns to you is properly aligned. When you're done with the memory
103 you hand it back to the library with the C<free()> call. C<free> has
104 one parameter, the pointer that C<malloc> returned. There are a couple of interesting ramifications to this.
106 Because malloc has to return an aligned pointer, it will round up the
107 memory allocation to make sure that the memory it returns is aligned
108 right. What that alignment is depends on your CPU, OS, and compiler
109 settings, but things are generally aligned to either a 4 or 8 byte
110 boundary. That means that if you ask for 1 byte, C<malloc> will
111 silently round up to either 4 or 8 bytes, though it doesn't tell the
112 program making the request, so the extra memory can't be used.
114 Since C<free> isn't given the size of the memory chunk you're
115 freeing, it has to track it another way. Most libraries do this by
116 tacking on a length field just before the memory it hands to your
117 program. (It's put before the beginning rather than after the end
118 because it's less likely to get mangled by program bugs) This size
119 field is the size of your platform integer, Generally either 4 or 8
122 So, if you asked for 1 byte, malloc would build something like this:
126 +------------------+ <----- the pointer malloc returns
132 As you can see, you asked for 1 byte but C<malloc> used 8. If your
133 integers were 8 bytes rather than 4, C<malloc> would have used 16 bytes
134 to satisfy your 1 byte request.
136 The C memory allocation system also keeps a list of free memory
137 chunks, so it can recycle freed memory. For performance reasons, some
138 C memory allocation systems put a limit to the number of free
139 segments that are on the free list, or only search through a small
140 number of memory chunks waiting to be recycled before just
141 allocating more memory from the system.
143 The memory allocation system tries to keep as few chunks on the free
144 list as possible. It does this by trying to notice if there are two
145 adjacent chunks of memory on the free list and, if there are,
146 coalescing them into a single larger chunk. This works pretty well,
147 but there are ways to have a lot of memory on the free list yet still
148 not have anything that can be allocated. If a program allocates one
149 million eight-byte chunks, for example, then frees every other chunk,
150 there will be four million bytes of memory on the free list, but none
151 of that memory can be handed out to satisfy a request for 10
152 bytes. This is what's referred to as a fragmented free list, and can
153 be one reason why your program could have a lot of free memory yet
154 still not be able to allocate more, or have a huge process size and
155 still have almost no memory actually allocated to the program running.
159 Perl's memory allocation scheme is a bit convoluted, and more complex
160 than can really be addressed here, but there is one common spot where perl's
161 memory allocation is unintuitive, and that's for hash keys.
163 When you have a hash, each entry has a structure that points to the
164 key and the value for that entry. The value is just a pointer to the
165 scalar in the entry, and doesn't take up any special amount of
166 memory. The key structure holds the hash value for the key, the key
167 length, and the key string. (The entry and key structures are
168 separate so perl can potentially share keys across multiple hashes)
170 The entry structure has three pointers in it, and takes up either 12
171 or 24 bytes, depending on whether you're on a 32 bit or 64 bit
172 system. Since these structures are of fixed size, perl can keep a big
173 pool of them internally (generally called an arena) so it doesn't
174 have to allocate memory for each one.
176 The key structure, though, is of variable length because the key
177 string is of variable length, so perl has to ask the system for a
178 memory allocation for each key. The base size of this structure is
179 8 or 16 bytes (once again, depending on whether you're on a 32 bit or
180 64 bit system) plus the string length plus two bytes.
182 Since this memory has to be allocated from the system there's the
183 malloc size-field overhead (4 or 8 bytes) plus the alignment bytes (0
184 to 7, depending on your system and the key length)
185 that get added on to the chunk perl requests. If the key is only 1
186 character, and you're on a 32 bit system, the allocation will be 16
187 bytes. If the key is 7 characters then the allocation is 24 bytes on
188 a 32 bit system. If you're on a 64 bit system the numbers get even
191 This does mean that hashes eat up a I<lot> of memory, both in memory
192 Devel::Size can track (the memory actually in the structures and
193 strings) and that it can't (the malloc alignment and length overhead).
197 Devel::Size, because of the way it works, can consume a
198 considerable amount of memory as it runs. It will use five
199 pointers, two integers, and two bytes worth of storage, plus
200 potential alignment and bucket overhead, per thing it looks at. This
201 memory is released at the end, but it may fragment your free pool,
202 and will definitely expand your process' memory footprint.
204 =head1 Messages: texts originating from this module.
210 =item "Devel::Size: Unknown variable type"
212 The thing (or something contained within it) that you gave to
213 total_size() was unrecognisable as a Perl entity.
219 These messages warn you that for some types, the sizes calculated may not include
220 everything that could be associated with those types. The differences are usually
221 insignificant for most uses of this module.
223 These may be disabled by setting
225 $Devel::Size::warn = 0
229 =item "Devel::Size: Calculated sizes for CVs are incomplete"
231 =item "Devel::Size: Calculated sizes for FMs are incomplete"
233 =item "Devel::Size: Calculated sizes for IOs are incomplete"
239 Doesn't currently walk all the bits for code refs, formats, and
240 IO. Those throw a warning, but a minimum size for them is returned.
242 Devel::Size only counts the memory that perl actually allocates. It
243 doesn't count 'dark' memory--memory that is lost due to fragmented free lists,
244 allocation alignments, or C library overhead.
248 Dan Sugalski dan@sidhe.org