Похоже, Джефф сделал неприятное открытие, исследуя использование памяти Rephlux и PHP в WACT .
Добавление следующего в комплект для тестирования модулей WACT (который в основном выполняет все, что имеет WACT);
foreach (array_keys($GLOBALS) as $key) {
echo "$key=" . strlen(serialize($GLOBALS[$key]));
}
Это показывает: ‘_PEAR_destructor_object_list = 146270’
Для поддержки этого драгоценного камня PEAR помещает ссылку на каждый экземпляр объекта, который когда-либо создавался, который наследуется от PEAR, в глобальную переменную _PEAR_destructor_object_list. Там объект остается до тех пор, пока не будет вызвана функция отключения деконструкции. Эта ссылка предотвращает сборку мусора любых объектов, унаследованных от PEAR или памяти, на которую они ссылаются в течение всего времени существования скрипта. И делает это без всякой веской причины.
Файл, о котором идет речь, это PEAR.php . И на самом деле я виноват в том, что расширил его в XML_HTMLSax (теперь нет в последней версии 3.0.0).
Я предполагаю, что есть другие проекты, такие как PhpDocumentor и все, кто выполняет задачи, подобные «сборке», через cron, используя PEAR-код, который также может обойтись, не жертвуя памятью ни к чему хорошему. Для веб-приложений на PHP это, вероятно, менее проблемная задача, но она все равно тратится впустую.
Возможно, в то время как разработчики пакетов PEAR рассматривают, куда обратиться с поддержкой PHP5 и нарушением обратной совместимости, другая миссия может изменить любой класс, который напрямую расширяет PEAR.php. Еще лучше сократить PEAR.php до единого класса с одним методом — isError () — который является единственной вещью, которую кто-либо действительно использует в любом случае.
(обновить) — сделать это двумя методами — isError и повыситьError — слишком быстро печатать…