We’ll start with the easiest assumption – Maugrim was too lazy to optimise his code from the start. Well, its pretty accurate, I didn’t – and admittedly I am quite possible of taking the easy option esp. in a hobby project. One of the problems I have with early optimising (and I take that as excluding the obvious PHP bad practices) is that when you program you start with “The Plan”. The Plan is way cool, sounds great, looks a dead cert on paper – and is so riddled with assumptions and unproven assertions that if you restrict it too much – by say optimising everything in sight – you can end up in a blackhole of despair along with unexpected bugs, a restricted design, and a fascinating lack of re-useability if taking the OOP approach.

In short you’ll screw up your work and it won’t be what you originally intended.

Off course not taking that approach means you’ll likely end up with a perfectly functioning program that’s fat, and possibly in danger of a heart attack. The next step then is to cut out the fat, push your application through a few hoops – read it, test it, stress it, and profile it. The 4 step super-diet for an application. Reading can possibly be a complete waste of time – if you’re a lone developer you’d need to obsess over your code. Its usually a very big deal to have a few extra eyes taking on that task, because they’ll almost certainly spark a few suggestions, get you thinking, and provide some inspiration. Those who read widely on a language usually do well. The best readers are performance fanatics – a somewhat rare breed unfortunately in PHP.

Step 2 is testing. To be honest I hate testing PHP. I do it anyway for select areas, but otherwise I’ll rely on my own grey matter and push it onto unsuspecting volunteers. Unit testing or function testing though is advisable. I can’t abide maintaining them, but I’ve used them in the earlier design phase.

Step 3 is profiling or stress testing. Either or – pick one, or do both. Profiling in PHP is often deemed a “waste of time”. Common perception that stinks to high heaven of inexperience outside the PHP globe. Profiling is good, profiling is easy, and Derrick Rethans provides the PECL extension XDebug which will do the job. Look Ma, no Zend Studio! XDebug is available for PHP 4.3.0 or greater. Dump it into your extensions directory, edit php.ini, set a few default values, and read the documentation on profiling. With XDebug2 Beta you’ll also need KCacheGrind to read the output log (don’t cry there’s a Windows alternative – WinCacheGrind). I’ve used this a few times in the last year, and it beats running around like a headless chicken waiting for a random user to suggest an improvement every month or so. It takes a little practice to figure out what the results say, but it’s worth a little effort to implement.

Stress testing I’m not hugely experienced with – I worked largely with low volume websites in the past where it didn’t really pose an obvious benefit. A few people rave about it however so look into it. PanamaJack recommends the Microsoft Web Stress Tool – if you’re on Linux you’re probably like me and wondering what Linux offers. I don’t know but I’ll go Google later.

I’ll start applying this process to Partholan, Quantum Star SE’s base backend and see what happens.

Related posts:

  1. QS3 will rock!…when its finished…