Derek Gallo

Its going to be a busy week because the following day, Saturday the 5th of April starts the second BarcampOrlando. The first day is geared towards developers and the second towards media. Don’t miss the official after party GeekOut ‘08! It should be a great day of learning and meeting fellow geeks in Orlando. I will be meeting Gregg early on dev day to help pickup the chairs for the event. If you would like to help unload or setup other aspects please come by.

Last, I would like to mention another geek meetup I along with some help from others am trying to revive/startup. OrlandoPHP will be a monthly meetup to discuss and learn everything PHP. If you dabble in PHP development or are interested in picking up more knowledge, stop on by! Our first meeting is scheduled for April 22nd at Devry from 7:00pm to 9:00pm. We are currently planning on reviewing the the available frameworks for php and discussing their pros and cons. If you have any questions or want to help get this going contact me.

I was talking about Object Oriented Design with someone the other day and the topic of making an object’s member variable read only came up. This is normally a simple task, simply define the member variable as protected or private within the class definition. That essentially makes it inaccessible to any code outside of the class it is a member of. One would then typically define an access function that allows outside code to read the variable. Here is an example:

class readOnly
{
    private $readOnlyVar;

    public function __construct()
    {
        $this->readOnlyVar  = 'This is read only';
    }

    public function getReadOnlyVar()
    {
        return $this->readOnlyVar;
    }
}

$readOnly = new readOnly();
echo $readOnly->getReadOnlyVar();

$readOnly->readOnlyVar = 'Trying to change this';

Running that code would produce the following output:

This is read only
Fatal error: Cannot access private property readOnly::$readOnlyVar

Read the rest of this entry »

We recently upgraded our servers at NFi from PHP 5.1.2 to PHP 5.2.2. We needed to upgrade to fix a bug in PHP’s COM object support. PHP 5.2.2 and PHP 5.2.1 have proven to be buggy on windows and broken things that have previously worked. Upgrading to 5.2.2 introduces a bug in the mysql module that keeps outputting the following at the end of every script:

Error in my_thread_global_end(): 3 threads didn’t exit

Wordpress is based upon MySQL so this obviously won’t work even though the error is present even when non MySQL code is being run. Downgrading to PHP 5.2.1 fixes that problem. You are not in the clear yet though. With PHP 5.2.1 there is a problem with the standard method Wordpress uses for permalinks.

The default method for using permalinks with Wordpress is to use the following URL style:

/index.php/2007/05/31/sample-post/

This will not work with PHP 5.2.1 though. It appears that it treats that location as the full path to the file to serve. It looks for the folder index.php instead of running the actual script. Since the folder doesn’t exist you get a 404 File Not Found Error.

Moving down yet again to PHP 5.2.0 will fix the problem and that is what I am now running with this blog. Alternatively you can use ISAPI Rewrite for WordPress which will rewrite your URL’s to not use the standard style. There is another popular Wordpress Permalink ISAPI Filter though that still relies upon the /index.php/%year%/%monthnum%/%day%/%postname%/ style. If you are using this filter you will need to use PHP 5.2.0.

I have always believed that iterating an array using a foreach loop in php was slower than iterating through the same array using a standard for loop. I figured this because there is no foreach equivalent in the underlying native code that php is run on and therefore a standard for loop didn’t require any additional translations.

I have never read any concrete evidence as to which is faster and a quick google search didn’t provide any results. Thus I decided to setup a benchmark test myself. The question in mind for me was “Is it more efficient to loop through a given array with a for or foreach loop?” This is also assuming a standard indexed array and not an associative array or hash table. since you would pretty much only use a foreach for that anyway.

The test involved first filling an array 100,000 items by just counting up from zero. A for loop counting to 100,000 was then setup along with a foreach loop set to iterate through the pre-filled array. An extra loop was setup around each of the test loops to do the iterations multiple times. I like to do this to get more of an average running time because using time as a measurement in a multitasking environment isn’t exactly 100% accurate. The body of each loop was merely a continue statement to move on to the next cycle.
Here is the php code:

set_time_limit(0);
$array = array();
echo "Filling array\n";

for($index=0; $index < 100000; $index++)
{
     $array[$index] = $index;
} 

$start = time();
for($iteration = 0;$iteration < 10; $iteration++)
{
     for($index=0;$index < 100000;$index++)
     {
          continue;
     }
}
$end = time();

$duration = $end - $start;
echo "For loop: ".$duration;$start = time();

for($iteration=0; $iteration < 10; $iteration++)
{
     foreach ($array as $value)
     {
           continue;
     }
}
$end = time();

$duration = $end - $start; echo "\nForeach loop: ".$duration; 

The results went against what I originally thought about php. I changed the iteration counts and the array size to make sure there wasn’t any affect due to loop setups or such. The results were nearly always the same. The for loop took twice as long to iterate than the foreach. Performance with any code is highly dependent on the context it is used in (especially in php) but this shows me my original thoughts were wrong.

Results for the above:

Filling array
For loop: 21
Foreach loop: 11

The benchmark was run on a Macbook Pro 1.8 Ghz Core Duo with 1.5GB ram. The test was run via CLI on php version 5.2.0. No optimizers or opcode cache was used. Try it out on different configurations and post your results in the comments.