Our first stab at it was utilizing ini format configs and the Zend_Config_Ini importer.  The configs were nice and clean, and had support built in for being environment aware.  This also is the approach the documentation seems to be pushing, almost anything that utilizes a config example in the documentation utilizes ini style configs.

A couple thoughts kept creeping into my mind though.  Whats the performance of converting ini file into the final config object going to be like?  How does it compare to other possible approaches to loading the config object?

Only one way to find out.  Time to fire up the PHP Raceway (my little homegrown testing framework for testing out these sort of things).  What I did was take the example config from the quick start documentation and added a config section for an array of data, then set up that config for trying out the three different approaches.  First is the standard ini way, second is building an array in php then building the config object from that, and third is creating a blank config object and loading it by hand.  Here are the racers.

The Racers

The INI approach

Instantiation Code:

Config File:

The PHP Array approach

Instantiation Code:

Config File:

The PHP Config Fill approach

Instantiation Code:

Config File:

The results

*times are in seconds*
laps = 10000

PHP Array Config Format is the WINNER!
total time = 2.70539808273
average time = 0.00027054

Ini Config Format results:
total time = 4.37592101097 which is 1.67052292824 slower than the winner
average time = 0.00043759 which is 0.00016705 per lap slower than the winner
this racer took 62% longer than the winner

PHP Config Fill results:
total time = 3.37267208099 which is 0.66727399826 slower than the winner
average time = 0.00033727 which is 6.673E-5 per lap slower than the winner
this racer took 25% longer than the winner

Conclusion

If speed is absolute biggest concern, I’d have to say go with the building of an array and passing it into the constructer.  The array aproach made our eyes burn, so we ended up going with the hand filling of the config object because the little bit of performance hit was worth the trade off of and easier to work with and read config file.

One huge thing of note.  I run xcache on my systems, and to be honest could not image running a production system without some sort of opcode cacher.  If you happen to not have access to an opcode cacher these results will change drastically.  Check out what happens when I turn xcache off:

*times are in seconds*
laps = 10000

PHP Array Config Format is the WINNER!
total time = 3.0291249752
average time = 0.00030291

Ini Config Format results:
total time = 4.26868700981 which is 1.23956203461 slower than the winner
average time = 0.00042687 which is 0.00012396 per lap slower than the winner
this racer took 41% longer than the winner

PHP Config Fill results:
total time = 4.76278781891 which is 1.7336628437 slower than the winner
average time = 0.00047628 which is 0.00017337 per lap slower than the winner
this racer took 58% longer than the winner

If you you’re not running an opcode cacher looks like you had better steer clear of the hand filling approach and go with the array for speed or ini for maintainability.
In the end this sort of micro-optimization may not gain you much in terms of noticeable real world performance, especially when you compare this to the cost of database or api queries.  But if you’re a speed freak, or are trying to cut down on the work your server is having to do during the day, this is some good food for thought.

I couldn’t figure out why a string kept coming out with gibberish on the end.  The app was truncating the string because it was too long, and the spot it was getting truncated at was at a single quote mark.  My initial thinking led me down a road where I thought perhaps it was one of those goofy quote marks and maybe it had gotten incorrectly encoded along the way and was not proper UTF-8.  After determining it was not an encoding problem one of the guys at work reminded me that UTF-8 characters can be mutibyte, and perhaps it had something to do with that.  After a little research, sure enough, the substr function I was using is one of dumb functions and was chopping that multibyte character in half, leaving only the gibberish.

In PHP < version 6 the core string functionality generally disregards the fact that charters could be multibyte, and just assumes 1 byte = 1 character.  In my research I ran across a great page that has a rundown of the different problematic string functions and their level of risk when it comes to dealing with UTF-8:   Handling UTF-8 with PHP [Web Application Component Toolkit].

My particluar situation was resolved by not chopping in the middle of words and instead finding and chopping at the preceding whitespace, but if you don’t have the luxury of tweaking your logic, I highly recommend taking a look at the Multibyte String Library, or procrastinate until PHP6 is out :)

The Accidental Businessman: Communities.

Now I’ve not actually been part of the Ruby community, but I can tell you that when I cross paths with someone who is from it, I generally come away feeling the same way that Marco does.

The contrast of the PHP and Python communities was pretty good.  Having recently dipped my toe into the Python community I would have to agree with the keg party vs study group metaphor.  Though I did tend to find the python folks overly harsh and often misinformed when it came to criticism of PHPers.  Maybe our party music is disturbing their studies :)

Curiosity got the better of me after hearing about some of the great stuff they were baking into the latest version.  So I downloaded the 6.7 M2 PHP version and have been using it exclusively for the last week.  Boy were my initial reactions dead wrong.  This thing absolutely rocks for PHP development.  It actually feels like and IDE built for PHP and not at all like PHP stuffed into a Java IDE (like Eclipse does).  Its fast and packed with features.  Some of the best features are not even the PHP ones.  The HTML, CSS, JS, and SVN support all seem top notch as well (something sometimes lacking in PHP focused IDEs).  The only sucky thing about it so far has been it’s name.  If any one is listening, please change the name to something that will not scare off non java-heads from trying this awesome IDE.

There is even a blog for the Netbeans for PHP.

I’ve used quite a large number of IDEs and editors over the years for my PHP hacking.  I’m not talking fired it up and made a bogus sample page, I’m talking using for months at a time to write real world projects.  Here is a quick rundown of some of my past PHP hacking tools of choice to give a perspective of where I’m coming from on this topic (these are in chronological):

• Textpad
  • I was n00b at one point :)
• Vim
  • Just too lacking in features for my taste, but still use for server side hacking and locally for quickly popping open a file.  Though I usually use MacVim these days.
• Dreamweaver
  • When I was still a bit wet behind the ears and not as hard core on the server side this helped to make me more productive with client side coding and was sufficient for my server side needs (especially since I was also doing ColdFusion work at that time).
• PHPEdit
  • Back when this was free and I needed something more robust than Dreamweaver for PHP coding this fit the bill quite nice.
• Eclipse
  • Yes, I have actually used this quite a bit.  At one point I was juggling lots of projects in lots of different languages at the same (PHP, ColdFusion, Python, bash, MySQL, XML, …) and wanted a way to streamline my workflow.  Eclipse got the job done.  It felt totally half baked and was full of bizarre Java language and concepts, but I was able find pluggins for everything I wanted it to do and it worked pretty well.
• Zend Studio <= 5 (before it sucked ass)
  • Once I was able to focus on strictly a LAMP environment I started looking for something more suitable.  I ran across Zend Studio and the wonders of server side debugging in PHP and I was hooked.  I used this IDE for almost 3 years and loved it (it’s non PHP support was a bit weak but…)
• Zend Studio 6 (when it sucked ass)
  • With version 6 of Zend Studio that decided to turn it into Zend Studio for Eclipse.  I’ve never seen such a colossal step backwards for a piece of software (with the possible exception of Windows Vista).  It didn’t support half the features it had in previous versions.  The old studios was fairly lean, but the new one came with all the Eclipse bloat and could barely get off the ground with the main project I was working on at the time.  Even though I could sluggishly code… I could not use the debugger without the thing crashing.  The love affair with Zend Studio was over and was time to move on.
• Komodo
  • I really like Komodo.  It was my ZendStudio rebound, and is more or less still my IDE of choice until I burn NetBeans in a little more.  I appreciate its support for multiple languages (use it for Python/Django on the Smoron project) and the javascript debugger.  Not exactly sure how I put this… its good and functional but doesn’t exactly have a huge WOW factor.
• NetBeans
  • Not sure if it is because its the “new” thing for me, or if it is because it is really that good.  But I’m currently WOWed :)

For a blast from my past check out this screen shot from the orginal “Unseen Web Services”