Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

It's already there.
memory_get_usage() and memory_get_usage(true)

I know memory_get_usage() and memory_get_usage(true). But they don't resolve the problem because the memory is not freed always when I unset a variable than memory_get_usage can return the same before and after creating a variable. See #48368. You said me that internal php memory is different from system allocated memory, and I want to access internal php memory. Memory_get_usage (with or without the first parameter) allow only to access to syem allocated memory.

Please reply

memory_get_usage(true) is the memory allocated from the system.
memory_get_usage() is the memory currently in use by PHP.

<?php

var_dump(memory_get_usage(), memory_get_usage(true));
$x = str_repeat('a', 4096);
var_dump(memory_get_usage(), memory_get_usage(true));
unset($x);
var_dump(memory_get_usage(), memory_get_usage(true));

Produces
int(332392) <-- Initial
int(524288) <-- system
int(336996) <-- After variable set
int(524288) <-- system
int(332916) <-- After variable unset
int(524288) <-- system

scott you are right, however it seems the behavior differs a bit when unset()ing small-enough variables.

memory_get_usage(false) does not takes into account the "small blocks cache" used by the allocator (not the same as the malloc()ed blocks cache).

This causes the reported memory usage to not always decrease when unset()ing a variable:

<?php
$foo = "bar";

var_dump(memory_get_usage());
var_dump(memory_get_usage());

unset($foo);
var_dump(memory_get_usage());
?>

int(91448) <-- first call
int(91696) <-- before unset
int(91696) <-- after unset (== before unset)

This patch may fix this:
Index: Zend/zend_alloc.c
===================================================================
RCS file: /repository/ZendEngine2/zend_alloc.c,v
retrieving revision 1.144.2.3.2.43.2.23
diff -u -p -r1.144.2.3.2.43.2.23 zend_alloc.c
--- Zend/zend_alloc.c	1 Apr 2009 16:55:47 -0000	1.144.2.3.2.43.2.23
+++ Zend/zend_alloc.c	30 May 2009 12:12:48 -0000
@@ -2496,7 +2496,11 @@ ZEND_API size_t zend_memory_usage(int re
 	if (real_usage) {
 		return AG(mm_heap)->real_size;
 	} else {
-		return AG(mm_heap)->size;
+		size_t usage = AG(mm_heap)->size;
+#if ZEND_MM_CACHE
+		usage -= AG(mm_heap)->cached;
+#endif
+		return usage;
 	}
 }

I unsderstand what you say but my request is different: when I posted bug #48368, jani@php.net answered me:
------------------------
unset != free. The memory is freed once the process shuts down. Until 
that, it's available inside the process. This is not a leak.
------------------------

I need a function that tell me the amount of this memory "available inside the process" or even better the difference between memory_get_usage() and this memory "available inside the process".

I don't think this is bogus, i think this must be an "open" feature request.

Thanks

What aren't you understanding?

memory_get_usage(true) = memory allocated to process from system
memory_get_usage() = memory actually in use for PHP

Therefore
memory_get_usage(true) - memory_get_usage()

That's the memory that has been allocated from the system but isn't used for variables yet.

Look this code:
----------------
<?
ini_set('memory_limit','300M');
class a {
}

echo "a - ".(memory_get_usage(true) - memory_get_usage())."\n";
$a=array();
for ($i=0; $i<=1000000; $i++) {
	$a[]= new a();
}
echo "b - ".(memory_get_usage(true) - memory_get_usage())."\n";
unset($a);
echo "c - ".(memory_get_usage(true) - memory_get_usage())."\n";
$foo=10000;
echo "d - ".(memory_get_usage(true) - memory_get_usage())."\n";
?>
-------------
That show

a - 201640
b - 774800
c - 685360
d - 685360
------------------------
If it is as you said the output near "d" should be different from the output near "c" but they are identical. I want to know how many internal mamory is used from the "$foo" variable. I know the the system memory is the same because php don't make always garbage collection but it collect on the request end bue i want to be able to know how much memory is interested by section of code. Using your code seems that $foo is registered on the void.

Thanks

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

The correction create an other problem: look this script:

<?
ini_set('memory_limit','300M');
class a {
}

echo memory_get_usage()."\n";
$a=array();
for ($i=0; $i<=1000000; $i++) {
	$a[]= new a();
}
echo memory_get_usage()."\n";
unset($a);
echo memory_get_usage()."\n";
$b=10000;
echo memory_get_usage()."\n";

?>

Regarding this code in bug #48368 you said me that unset != free. The memory can remain occupied also after I unset an array, that memory is reused when I set a new variable.

Now it is is possibile to check $foo dimension but the memory is not reused. The output of the script is:

325792
230042232
33847560
33847640

It seems that the memory between 325792 and 33847560 is lost, it is not reused when I set $foo.

PHP uses an array internally to store all objects. When you create more objects, the array is grown. When you destroy some objects, the array is not resized, so that creating other objects is faster.

This is the difference you see; ~32 bytes per object.

This is not due to the allocator. There is a few other caches of this kind in PHP that make it running faster.

But this cache would be used When I create $foo the dimensione grows from 33847560 to 33847640 (80 bytes extra). This didn't happen using php3.0rc2 but happens using last snapshot

In rc2 this was hidden by the allocator's own cache. This has been fixed in CVS and this is why the last snapshot behaves differently.