Dan Ackroyd wrote on 19/05/2015 14:08:
* When gc_collect_cycles is called (and potentially other functions), at the end of that function check whether the amount of memory being used is less than reset level for each trigger. If so reduce the current memory limit to the lowest trigger level.
The only flaw I see in this approach is that the majority of memory deallocation is done transparently be the ref-counting mechanism, not any particular function, and the user should be able to trigger this manually.
For instance, you might have an EntityRepository which caches all the entities it's loaded thus far in the script to save DB round trips, and calling clearCache() on this repository might free a significant amount of memory.
It would probably make sense for the memory level to be checked against reset levels immediately after the low-memory callback returns, so that users can deliberately take advantage of such deallocations. However, that still leaves the case of that method being called during normal flow, and requiring a call to gc_collect_cycles just for the side-effect of resetting memory limits seems a bit odd.
I don't know enough about the memory manager to know, but presumably at the moment memory_limit is checked on every allocation? Could a similar check be made on deallocation?
Having multiple levels configured doesn't actually have any extra performance cost, except in the case where they are all passed at once - you just store the "current" level, and test whether you have reached the next level up or down. If a single deallocation drops you from 20MB to 2MB, you first register that the 16MB reset limit has been reached, and *only then* perform an extra check if the 8MB reset limit has also been reached.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
