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.