Several months back I wrote a hackish PHP extension to natively connect and talk with Thunderstone's texis SQL daemon and now it's just sitting around unused and unfinished. What I can't figure out is whether there's anyone out there who'd actually want such a beast - we were only thinking about going that route because we had a poorly deployed search index running out of texis, and replacing vortex with PHP seemed like a good idea.

Now that chx has beaten me to it, I'm going to profile and patch and find all the low hanging fruit to cache in drupal. Here's an improvement to the module_hook function.

I've been playing with callgrind, xdebug, and kcachegrind to profile drupal. I'll go over the details of my results in a future blog entry, but if you want the short story just check out Rasmus's directions. Rasmus has given lots of talks with similar names to "Getting Rich with PHP5" and I'll leave it to the reader to google and find slides from this talk.

Profiling is an iterative process, and after awhile I might blog about it with something more concrete. But for now, I have early results.

I'm working on a blog entry comparing the performance of different templating engines (Smarty, Savant, etc.) and one thing I wanted to do was use http_load to provide data points regarding performance. Trouble is, while http_load kindly provides connection times and first response times means, minimums, and maximums, it doesn't provide a standard deviation. Given that my test environment is a multi-user operating system and other things are running, I am a bit concerned that measurements might contain extra variation because of background processing time.

While not a perfect solution, a good start is getting the standard deviation of measurements. Now, I can compare means with more confidence (ha, ha, a statistics pun) in determining what makes a difference. So, this hack is adding standard deviations to http_load output.