On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote:
-----Original Message-----
From: Ronald Chmara [mailto:[EMAIL PROTECTED]
What is the *actual cost and complexity* involved in implementing
(possibly many) different user-selectable memory management systems,
and what other future benefits/drawbacks might we see by doing such a
thing? (GC is big now, but what about memory pools per mod_auth user,
or SHM/SEM pools, or tuning amounts of memory per function, etc...)
I will now apologize to everybody who I just made cry, scream, or
damage their furniture, as I didn't mean to hurt you, just trying to
stimulate ideas.
Hi Ronald,
PHP 5.2.x already supports the ability to hook in different "page"
managers. In PHP 5.3 you can also override the memory allocation
functions. However, this would not include garbage collection like
algorithms which actually require changes in the core PHP data type
such
as zvals. In fact the garbage collection adds memory to the basic
datatypes which is why I suggested to either always make these
changes,
or don't make them so that we retain binary compatibility across all
builds of PHP.
So overriding basic memory allocation functions, yes, ability to
provide
various GC implementations, no.
Okay, so, without this patch, I can allocate mem, and destroy it, on
a per page level, but not on a zval level, and the choice is:
a) zval (etc.) destruction with this patch, which has a 5% speed hit
at times (varies per test)
b) no patch, no change
c) something which hasn't been thought of yet?
I'd have to (sadly) ask that anything that slows down PHP by 5%, to
improve performance for programmers that, uhm, "leak" or otherwise
gobble RAM, that they, uhm, refactor their code as professional
programmers.
Thanks for clearing it up for me, Andi.
-Bop
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
