Michael Dowling has a recent post to his site comparing the performance of hash lookups versus array searches.

A common programming requirement is to match a string against a set of known strings. For example, let’s say you were iterating over the words in a forum post and testing to see if a word is in a list of prohibited words. A common approach to this problem is to create an array of the known prohibited words and then use PHP’s in_array() function to test if the string is found in the list. However, there’s a simple optimization you can make to significantly improve the performance of the algorithm.

He includes two pieces of sample code - one showing the searching of an array using in_array and the other running an isset to locate a key. He points out that the in_array method is quite a bit slower than the hash (key) lookup and includes a benchmark script to prove it.The results are pretty clear, with the hash lookup coming in about 480% faster than the in_array. He also points out that as the size of the strings you're comparing grows, the performance of in_array drops even more.

Samantha Quinones has a new post today about something that has been known to trip up both new and experienced PHP developers - PHP's dynamic type juggling.

No matter how popular an activity it is, I really don’t like to bash on PHP. Every language has its flaws when you look closely enough, and if PHP wears its idiosyncrasies a little closer to the surface than most, I think it makes up for it in other ways. PHP’s handling of types, however, is confusing at best and at worst completely deranged.

She goes on to talk about the issues with type comparisons and how much trouble using the "==" (double equals) versus the "===" (triple equals) can potentially cause. While it's easier for new PHP developers to get caught by this issue, even experienced devs might miss it. She gives an example of a time in her own development involving the comparison of strings against constants and in_array's non-string type comparisons.

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.