SS>> If you are concerned about PHP's memory footprint, then SS>> relying on your own memory management makes matters only SS>> worse. SS>> SS>> Why? It would effectively lock up memory in a PHP-specific SS>> area, so that other 3rd party software (web server, SS>> libraries) won't have access to unused resources anymore.
That's right. However, I am not sure if it is worse of better. Actually, I am concerned with both performance (which malloc is known to hurt - malloc is pretty costy operation AFAIK, that's why we have memory cache) and memory footprint. Of those, I am concerned with the former much more than the latter. However, if we have 640% overhead on each zval allocation, this starts to bother me more - because maybe if those 640% aren't available to 3rd-party anyway, so why not make them available at least for ourselves? And maybe we could do even with less than 640%... Again, I do not propose to make _all_ mallocs use spearate space. I'm thinking along the lines of improving those mallocs that are most frequent, most traceable and identifiable. The rest can be happy with mallocs. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
