Thanks to some late nights and doting grandmothers, I’ve been able to work extra-hard on Feedwhip’s performance issues the past few days.

For a while there, I was in despair. Using my framework to render a static, three-word web page was giving me a throughput of 15 pages/sec, and the connect time was a horrific 300ms. At the PHP conference, Rasmus Lerdorf had said anything more than 10ms is just too slow. 10 milliseconds!

Well, I got to work. My framework automatically loads in all the PHP code you need right at the start, but that means it also loads the code you don’t need. Loading the models, controllers, and helper classes on demand brought the connect time down to 265ms, 220ms, and 200ms respectively. Better, but not really in the ballpark.

Profiling the code was giving unexpected results. Retrieving the value of a variable in my model class, an action which occurs a bajillion times, was really slow. It turns out that calling any functions in PHP, even ones which just return a value, is horrendously slow. So, I spent all day today looking at my loops and storing values locally outside of the loops.

Frankly, the discovery that PHP functions are slow was a big disappointment. My wonderfully architected and abstracted framework, which uses lots of virtual functions and inheritance, is just plain slow. I’ve now got a new perspective on how to code in PHP: use lots of locally cached values and avoid function calls. Unfortunately, when you’re more than a year into a function-call-heavy framework, things can be hard to change.

Because I had to touch so much code along the way, these changes will need a lot of testing. It’ll probably be a while — maybe a week — before they can be pushed live.