I thought, as reference, I’d do up a post concerning performance and optimisation in Astrum Futura. Mainly to get my thought processes in text, and take a look at where performance is lacking.

The main driver of performance at the moment, in the absence of reems of game specific code is the Zend Framework. The ZF is currently reaching a v0.60 preview release in subversion (should be release next month) and an interesting discussion took place last week on the ZF mailing lists concerning this blog post by Paul M. Jones comparing four framework. In a simple minimalistic "Hello World!" application using each framework’s most minimum setup possible, and measuring requests per second (on a local PC), the ZF came last.

The main causes of this was the pure OOP approach. Each component has a few Exception classes, each in a separate files, which were loaded (as all ZF files are) using require_once(). Add to that the possible use of a static loading method which did weird and wonderful I/O filesystem checks and all that work created a major drag. That may be addressed properly in the future – until a 1.0 release the idea of optimisation is still largely considered premature optimisation. At least one small improvement was made – the use of Reflection has been largely removed from the many Controller classes. Reflection in PHP5 is nice, neat, and very expensive.

The Astrum Futura approach is to wait and see. Until then we’ve added an __autoload function, and are prepared to strip all instances of require_once() calls from files we distribute in a release. That in combination with autoloading would ease the burden a fair bit. A release is months away of course, so wait and see is the only reasonable stance right now.

Another future performance driver is the database. This gets interesting however, in that we can’t consider the database purely in isolation. By itself we can rely on a mix of query caching (on the few shared hosts who actually bother to check their MySQL configuration), the use of InnoDB and MEMORY (HEAP) storage solutions for tables (again MySQL), and the usual pretension that 4th level normalisation doesn’t exist ;-).

In AF, we also have to deal with how database results are handled. In general terms, an AJAX frontend does not typically rely on HTML input. Rather we receive responses in a strict data-only format such as XML or JSON. JSON in particular is the most useful since it’s Javascript’s native object notation. XML is more complex since it requires using Javascript’s DOM to manipulate. One of the focuses for near static data will be utilising caching extensively – not just server side, but also in the client. One of our main concerns, and one of the reasons we’re coding to PHP5.2, using MySQL more productively (no MyISAM crap here), and actively seeking ways of caching data, is the fact that the interface is AJAX enabled.

AJAX gives a nice warm fuzzy feeling when you see it in action. But if used extensively in the wrong way it can create a ton of problems. The simplest explanation is that AJAX should nearly always increase a user’s productivity – it’s not just eye candy ;-). The more productive they are, the fewer server requests they should need for a given task. The disadvantage is that you can easily wind up with a task which rather than taking one or two big page reloads to complete, takes a dozen or more small AJAX updates. If those small updates are slow, and add up to a larger request time and larger bandwidth takeup than the single big request you started with – then something went a bit wrong. Caching both on the server side, and especially on the client side reduces the number of small requests for static data. The fewer the better…

Now, if only these good intentions converted into reality in the near future…;-)