<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Thu, 20 Nov 2008 11:53:01 -0600</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Brian Moon's Blog: in_array is quite slow]]></title>
      <guid>http://www.phpdeveloper.org/news/10357</guid>
      <link>http://www.phpdeveloper.org/news/10357</link>
      <description><![CDATA[<p>
<i>Brian Moon</i> had <a href="http://brian.moonspot.net/2008/06/05/in_array-is-quite-slow/">a problem</a> - 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 <a href="http://www.php.net/in_array">in_array</a>, something he comments on as being "quite slow".
</p>
<blockquote>
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.  
</blockquote>
<p>
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.
</p>]]></description>
      <pubDate>Fri, 06 Jun 2008 09:36:47 -0500</pubDate>
    </item>
  </channel>
</rss>
