Programming
Article
By Harry Fuecks

The garbage you can’t dispose of…

By Harry Fuecks

Looks like Jeff’s made an unpleasant discovery while exploring Rephlux and PHP memory usage in WACT.

Adding the following to WACT’s unit test suit (which basically executes everything WACT has);


foreach (array_keys($GLOBALS) as $key) {
echo "$key=" . strlen(serialize($GLOBALS[$key]));
}

This shows up: ‘_PEAR_destructor_object_list=146270’

To support this gem, PEAR puts a reference to every object instance ever instantiated that inherits from PEAR into the global variable _PEAR_destructor_object_list. There the object stays until the deconstruction shutdown function is called. This reference prevents garbage collection of any of objects inheriting from PEAR or the memory they reference during the lifetime of the script. And it does this for no good reason at all.

The file in question is PEAR.php. And in fact I’m the guilty party for having extended from it in XML_HTMLSax (now gone with latest 3.0.0 release).

My guess is there are other projects like PhpDocumentor and anyone doing “build-like” tasks via cron, using PEAR code that could also do without donating memory to no good purpose. For PHP web applications it’s likely less of an issue but it’s still wasted overhead.

Perhaps while PEAR package developers consider where to go with PHP5 support and breaking backwards compatibility, another mission could modifying any class that extends PEAR.php directly. Better yet cut down PEAR.php itself to be a single class with a single method – isError() – which is about the only thing anyone is really using anyway.

(update) – make that two methods – isError and raiseError – typing too fast…

Recommended
Sponsors
The most important and interesting stories in tech. Straight to your inbox, daily. Get Versioning.
Login or Create Account to Comment
Login Create Account