1Devel::Size(3) User Contributed Perl Documentation Devel::Size(3)
2
6 Devel::Size - Perl extension for finding the memory usage of Perl vari‐
7 ables
8
10 use Devel::Size qw(size total_size);
11 my $size = size("A string");
13 my @foo = (1, 2, 3, 4, 5);
15 my $other_size = size(\@foo);
16 my $foo = {a => [1, 2, 3],
18 b => {a => [1, 3, 4]}
19 };
20 my $total_size = total_size($foo);
21
23 This module figures out the real sizes of Perl variables in bytes.
24 Call functions with a reference to the variable you want the size of.
25 If the variable is a plain scalar it returns the size of the scalar.
26 If the variable is a hash or an array, use a reference when calling.
27
29 size($ref)
30 The "size" function returns the amount of memory the variable returns.
32 If the variable is a hash or an array, it only reports the amount used
33 by the structure, not the contents.
34 total_size($ref)
36 The "total_size" function will traverse the variable and look at the
38 sizes of contents. Any references contained in the variable will also
39 be followed, so this function can be used to get the total size of a
40 multidimensional data structure. At the moment there is no way to get
41 the size of an array or a hash and its elements without using this
42 function.
43
45 None but default, but optionally "size" and "total_size".
46
48 Please note that the following discussion of memory allocation in perl
49 is based on the perl 5.8.0 sources. While this is generally applicable
50 to all versions of perl, some of the gory details are omitted. It also
51 makes some presumptions on how your system memory allocator works so,
52 while it will be generally correct, it may not exactly reflect your
53 system. (Generally the only issue is the size of the constant values
54 we'll talk about, not their existence)
55 The C library
57 It's important firtst to understand how your OS and libraries handle
59 memory. When the perl interpreter needs some memory, it asks the C run‐
60 time library for it, using the "malloc()" call. "malloc" has one param‐
61 eter, the size of the memory allocation you want, and returns a pointer
62 to that memory. "malloc" also makes sure that the pointer it returns to
63 you is properly aligned. When you're done with the memory you hand it
64 back to the library with the "free()" call. "free" has one parameter,
65 the pointer that "malloc" returned. There are a couple of interesting
66 ramifications to this.
67 Because malloc has to return an aligned pointer, it will round up the
69 memory allocation to make sure that the memory it returns is aligned
70 right. What that alignment is depends on your CPU, OS, and compiler
71 settings, but things are generally aligned to either a 4 or 8 byte
72 boundary. That means that if you ask for 1 byte, "malloc" will silently
73 round up to either 4 or 8 bytes, though it doesn't tell the program
74 making the request, so the extra memory can't be used.
75 Since "free" isn't given the size of the memory chunk you're freeing,
77 it has to track it another way. Most libraries do this by tacking on a
78 length field just before the memory it hands to your program. (It's put
79 before the beginning rather than after the end because it's less likely
80 to get mangled by program bugs) This size field is the size of your
81 platform integer, Generally either 4 or 8 bytes.
82 So, if you asked for 1 byte, malloc would build something like this:
84 +------------------+
86 ⎪ 4 byte length ⎪
87 +------------------+ <----- the pointer malloc returns
88 ⎪ your 1 byte ⎪
89 +------------------+
90 ⎪ 3 bytes padding ⎪
91 +------------------+
92 As you can see, you asked for 1 byte but "malloc" used 8. If your inte‐
94 gers were 8 bytes rather than 4, "malloc" would have used 16 bytes to
95 satisfy your 1 byte request.
96 The C memory allocation system also keeps a list of free memory chunks,
98 so it can recycle freed memory. For performance reasons, some C memory
99 allocation systems put a limit to the number of free segments that are
100 on the free list, or only search through a small number of memory
101 chunks waiting to be recycled before just allocating more memory from
102 the system.
103 The memory allocation system tries to keep as few chunks on the free
105 list as possible. It does this by trying to notice if there are two
106 adjacent chunks of memory on the free list and, if there are, coalesc‐
107 ing them into a single larger chunk. This works pretty well, but there
108 are ways to have a lot of memory on the free list yet still not have
109 anything that can be allocated. If a program allocates one million
110 eight-byte chunks, for example, then frees every other chunk, there
111 will be four million bytes of memory on the free list, but none of that
112 memory can be handed out to satisfy a request for 10 bytes. This is
113 what's referred to as a fragmented free list, and can be one reason why
114 your program could have a lot of free memory yet still not be able to
115 allocate more, or have a huge process size and still have almost no
116 memory actually allocated to the program running.
117 Perl
119 Perl's memory allocation scheme is a bit convoluted, and more complex
121 than can really be addressed here, but there is one common spot where
122 Perl's memory allocation is unintuitive, and that's for hash keys.
123 When you have a hash, each entry has a structure that points to the key
125 and the value for that entry. The value is just a pointer to the scalar
126 in the entry, and doesn't take up any special amount of memory. The key
127 structure holds the hash value for the key, the key length, and the key
128 string. (The entry and key structures are separate so perl can poten‐
129 tially share keys across multiple hashes)
130 The entry structure has three pointers in it, and takes up either 12 or
132 24 bytes, depending on whether you're on a 32 bit or 64 bit system.
133 Since these structures are of fixed size, perl can keep a big pool of
134 them internally (generally called an arena) so it doesn't have to allo‐
135 cate memory for each one.
136 The key structure, though, is of variable length because the key string
138 is of variable length, so perl has to ask the system for a memory allo‐
139 cation for each key. The base size of this structure is 8 or 16 bytes
140 (once again, depending on whether you're on a 32 bit or 64 bit system)
141 plus the string length plus two bytes.
142 Since this memory has to be allocated from the system there's the mal‐
144 loc size-field overhead (4 or 8 bytes) plus the alignment bytes (0 to
145 7, depending on your system and the key length) that get added on to
146 the chunk perl requests. If the key is only 1 character, and you're on
147 a 32 bit system, the allocation will be 16 bytes. If the key is 7 char‐
148 acters then the allocation is 24 bytes on a 32 bit system. If you're on
149 a 64 bit system the numbers get even larger.
150 This does mean that hashes eat up a lot of memory, both in memory
152 Devel::Size can track (the memory actually in the structures and
153 strings) and that it can't (the malloc alignment and length overhead).
154
156 Devel::Size, because of the way it works, can consume a considerable
157 amount of memory as it runs. It will use five pointers, two integers,
158 and two bytes worth of storage, plus potential alignment and bucket
159 overhead, per thing it looks at. This memory is released at the end,
160 but it may fragment your free pool, and will definitely expand your
161 process' memory footprint.
162
164 Errors
165 "Devel::Size: Unknown variable type"
167 The thing (or something contained within it) that you gave to
168 total_size() was unrecognisable as a Perl entity.
169 warnings
171 These messages warn you that for some types, the sizes calculated may
173 not include everything that could be associated with those types. The
174 differences are usually insignificant for most uses of this module.
175 These may be disabled by setting
177 $Devel::Size::warn = 0
179 "Devel::Size: Calculated sizes for CVs are incomplete"
181 "Devel::Size: Calculated sizes for FMs are incomplete"
182
184 Doesn't currently walk all the bits for code refs, formats, and IO.
185 Those throw a warning, but a minimum size for them is returned.
186 Devel::Size only counts the memory that perl actually allocates. It
188 doesn't count 'dark' memory--memory that is lost due to fragmented free
189 lists, allocation alignments, or C library overhead.
190
192 Dan Sugalski dan@sidhe.org
193 Small portion taken from the B module as shipped with perl 5.6.2.
195 Maintained now by Tels <http://bloodgate.com>
197
199 Copyright (C) 2005 Dan Sugalski, Copyright (C) 2007 Tels
200 This module is free software; you can redistribute it and/or modify it
202 under the same terms as Perl itself.
203
205 perl(1), Devel::Size::Report.
206perl v5.8.8 2007-06-10 Devel::Size(3)