Paul Reinheimer has a reminder shown in his latest post about optimizing your scripts - don't forget the basics like unset.

A colleague called me over today for some help with a memory usage issue in his PHP script. The script was performing the basic (but critical) task of importing data, pulling it in from MySQL in large chunks, then exporting it elsewhere. He was receiving the wonderful "Fatal error: Allowed memory size of XXXX bytes exhausted (tried to allocate YY bytes)" error message. [...] I fixed the memory usage exceeded problem with an unset(), at the end of a loop.

The loop was structured such that the large amounts of data were just being held in memory over and over again, resulting in a huge stackup that can easily cause the "Allowed memory size exhausted..." message.

There are better architectures available to avoid the issue entirely (like not storing everything in the array, just to iterate over it later) but they're an issue for a different post. For a very simple base case demonstration of the issue take a look at the simple example.

DevShed continues their series on the "magic functions" in PHP with this new tutorial, a closer look at the __isset and __unset functions.

Overloading properties is only one of the many useful things that can be accomplished with magic functions. It’s also possible to perform additional tasks when working with the "isset()" and "unset()" PHP functions, but in this case by using another set of complementary functions, called "__isset()" and "__unset()" respectively.

In the examples he shows how to use the functions to see if a property has been set or to unset it and remove it from the object (could be helpful when working with private class properties).

In a new article to his blog, Ryan Campbell has expressed some concerns in the amounts of memory that some of the object oriented practices in PHP are using these days.

It’s hard to imagine pushing the limits of object oriented PHP so far that your web servers choke, but the truth is those limits are reached faster than you think. [...] While replacing objects with arrays when possible makes things a little better, the most performance friendly approach involves appending strings. For your convenience, we’ve run some tests that measure page execution times and memory usage to create the following guideline to help you plan out what areas of your code may have to break away from an object oriented nature.

He shares some benchmarks of the memory use for different variable types - strings, arrays and objects - giving load times and the amounts of memory used. He mentions three workarounds that could help (unset, static methods and paging) reduce the memory consumption of your script.

Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

On the PHP Security Blog today, this note has been posted, a notification that a critical vulnerability has finally been fixed - the unset() issue.

Because there are meanwhile a lot of rumours about this vulnerability in the underground and because the PHP 4.4.3 release announcement does not mention this critical hole at all I wrote up a little article about it, which you can read here.

The article (from Hardened PHP) describes the issue - a problem in the hash tables of the Zend Engine, specifically the zend_hash_del_key_or_index function. The logic contained inside the function can find the wrong "bucket" of information and remove it. He also includes PHP code examples that show the issue in action.

To be protected, it's recommended to update to the latest versions of PHP that have been released - 4.4.3 and 5.1.4.

On the PHP Security Blog today, this note has been posted, a notification that a critical vulnerability has finally been fixed - the unset() issue.

Because there are meanwhile a lot of rumours about this vulnerability in the underground and because the PHP 4.4.3 release announcement does not mention this critical hole at all I wrote up a little article about it, which you can read here.

The article (from Hardened PHP) describes the issue - a problem in the hash tables of the Zend Engine, specifically the zend_hash_del_key_or_index function. The logic contained inside the function can find the wrong "bucket" of information and remove it. He also includes PHP code examples that show the issue in action.

To be protected, it's recommended to update to the latest versions of PHP that have been released - 4.4.3 and 5.1.4.