11

Possible Duplicate:
What is the overhead of using PHP int?

Can somebody explain me, why creation of an integer in PHP, costs 72 bytes?

var_dump(memory_get_usage()); //49248 bytes  
$a = 255;  
var_dump(memory_get_usage()); // 49320 bytes
Community
  • 1
  • 1
zim32
  • 2,561
  • 1
  • 24
  • 31
  • 21
    PHP is a european language. The variable needs health insurance, a pension, a social security number... (Seriously - nice question!) – Pekka Sep 09 '11 at 07:42
  • Aha! Found it! Enjoy. That might not be an "exact" duplicate because it doesn't spell out why the space is required to begin with, but it does address the other questions about size differences on 32-bit and 64-bit platforms. I am not sure if the *variable itself* (e.g. not just the value) also factors into the memory usage...? –  Sep 09 '11 at 08:02
  • 3
    Does it actually increase by 72 bytes *every time* you create an int? – Hannesh Sep 09 '11 at 08:06
  • @Hannesh Each integer is a new value ("object") -- why would it not? Python "caches" small integers. PHP might do this as well, but 255 might be outside the range if it does. (I don't know if it does though). –  Sep 09 '11 at 08:08
  • 1
    Related: [PHP at the Core: A Hacker's Guide to the Zend Engine](http://www.php.net/manual/en/internals2.php) – Álvaro González Sep 09 '11 at 08:30
  • @pst: 72 bytes is a lot. – Lightness Races in Orbit Sep 09 '11 at 08:48
  • @Tomalak Geret'kal It's similar in Python (for non-cached ints) and Ruby for BigNums (> 30-bits) and Java for Integers (the objects, not the primitives). The actual usage will vary, but it's all "significantly more" than 4 bytes. It generally takes specialization of actual "primitive" integer values (as Ruby does for sub 30-bit values) or Java does with the `int` primitive or C# does with the structural types to avoid such overhead. –  Sep 09 '11 at 17:50

3 Answers3

2

It is probably due to the way PHP allocates memory. The files are not compiled down into binary so they are not pushing four bytes onto the stack or being allocated on the heap, but rather allocating memory on a virtual stack.

Anthoni C
  • 143
  • 1
  • 1
  • 6
2

I don't have extensive knowledge of PHP internals, but the concept is that when you create a variable with an integer value, PHP internally allocates a structure (such structures are usually called variants) that is capable of holding any type of value in the language (which includes object types, functions, etc). This is bound to require more than a lowly 4 bytes.

With that out of the way, the question that remains is why 72 (and not for example 42)? For an answer to this we 'd need to examine not only the C source (to see exactly what is allocated and what its memory footprint is) but also the implementation of memory_get_usage (to see how exactly it counts memory usage).

Update: I feel I need to stress the "how it counts memory usage" part more.

It is entirely possible that the allocation of a new variable causes PHP's memory allocator to reserve a block of memory from the C heap substantially larger than what it needs to satisfy the variable allocation request (it can also decide to keep this memory future use even after you e.g. unset the variable).

If memory_get_usage wants to count the whole memory block as "used", then you could even see a simple integer variable cause usage to go up by, say, 1K (if things were as simple as I have described so far, an additional integer allocation would then not cause memory usage to increase).

My point here is that you cannot call the memory usage results unexpected until you can fully define what the expected results are. And this is not possible without looking at the source for memory_get_usage.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • Ok. Lets asume creating a variable 4 bytes for actual data 2-4 bytes for data type (zval) 2-4 bytes for refcount 2-4 bytes fot is_ref Also i thought that creating first variable can take reources for creating inner structures for scope and symbolic table but creating another var $b = 255 causes another 72 bytes usage... O_o – zim32 Sep 09 '11 at 07:51
  • On codepad.org the integer needs 188 bytes: http://codepad.org/51oCNQM6 Even when I call `unset()`, the memory isn't freed! – ComFreek Sep 09 '11 at 07:55
  • @user603003 It is a 64-bit platform, where the one in the post is 32-bits. There is a SO question that covers this... that I can't find of course. It has to do with pointer sizes as well as padding and alignment. –  Sep 09 '11 at 07:56
  • @zim32: Updated the answer, please take a look. – Jon Sep 09 '11 at 08:02
  • Looks like possible variant. but why adding another variable? saying $b = 255 causes another 72 bytes... – zim32 Sep 09 '11 at 08:06
  • ...it has more to do with [the structure PHP uses for values](http://stackoverflow.com/questions/5972170/what-is-the-overhead-of-using-php-int) (they are all objects)... –  Sep 09 '11 at 08:07
  • I was dissapointed.... I thought max 16-20 bytes but not 72... ( – zim32 Sep 09 '11 at 08:13
0

Setting any variable will use up a particular amount of memory, so that you can do the following without any errors:

$a = 100;
//...then later in the code
$a = 100000;
//or
$b = "hello";
//...then later in the code
$b = "hello world this is a long string to show how long a string can be.";

It may also be because PHP is a preprocessing language, not a program that converts your code to binary then the binary code is run.

kirb
  • 2,033
  • 1
  • 18
  • 28