Professional PHP

Jon Ramsey came up with a continuous integration tool called Rephlux. Rephlux periodically checks out your code from CVS and runs your unit tests on it. It produces a RSS feed of test failures and a RSS feed of CVS revisions. How cool is that?

In the future it should be possible to automatically build releases and documentation when all the tests pass. Hopefully, this will help improve our record of releasing on the WACT project. With one formal release in nearly a year of active development, our record is dismal as Harry diplomatically points out.

Jon is running Rephlux remotely for WACT right now because we are having a problem getting our full test suite to run in the 8M limit that sourceforge imposes on PHP. We have 97 test cases, 541 test functions, and 1927 assertions in our test suite. This will only grow. The full test suite includes over 350 PHP files when it runs.

Since there isn’t much we can do about unincluding files to free up memory, I decided to take a look at the data that gets stored to see if there was any low hanging fruit there. I wanted to look and see if any of the code we are using keeps any data in global variables that it might be able to release when done to allow the space to be garbage collected.

So, I added a quick and dirty little hack to get an idea of the size of the various global variables that were left over after a test run.

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

Most of the globals that were left over were tiny, but there was one that stood out. That was something from PEAR:

 
_PEAR_destructor_object_list=146270
 

Looking in to this further I found that the PEAR base class registers a rather dubious destructor for every object that inherits from it:

 
    function _PEAR() {
        if ($this->_debug) {
            printf("PEAR destructor called, class=%sn", get_class($this));
        }
    }
 

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.

I’ve expressed my opinion of pear.php before and this only reinforces it.

The only PEAR module that WACT requires is XML_HTMLSax, a handy parser for HTML with an XML parsing interface. I’ve always been a little bit uncomfortable with its dependency on pear.php and the deployment issues that this introduces into WACT. WACT also has optional components that reference other PEAR packages, such as PEAR::DB, PEAR::MDB and PEAR::MDB2. Fortunately a more typical WACT use case only instantiates a handful of PEAR objects.