I’ve made it a focus of mine over the next few months to tighten my belt on tests and profiling, specifically with my WordPress projects. I’ve been doing a lot of tinkering with Vagrant, VVV, Xdebug, and xhprof with the specific intent of easily profiling my code. I was quick to discover that while these tools are fantastic, they’re way too much for my use case.
Please put down the pitchforks, VVV pennants, and flamethrowers for a second.
I understand why tools like VVV are such a draw for so many developers, I get it. For me however, because of the projects I choose to take on and the stance I have behind said projects, I need to stick with the convention WordPress has put in place. Naturally that means (among other things) working with PHP 5.2.
Again: no pitchforks please.
I understand that PHP 5.2 is ridiculously out of date. I also fully understand the dichotomy between WordPress having the power to force the hand of hosts the world over and WordPress’ decision to respect their users enough to not blow up half the world. It’s a raging war that I can only see continuing on until adoption rates have slowed enough to be acceptable, at which point PHP will have moved beyond these issues to others. I have chosen WordPress for many more reasons than it’s chosen minimum PHP version; for me it’s not worth moaning about.
That said, the major draw to the latest and greatest in local development environments have little to no bearing on me. While VVV is perhaps the most killer thing to happen to local development to date, I still don’t use it because I’d need to tinker with who knows what to get it running an environment that matches WordPress’ minimum requirements instead of something more ideal. Messing around with configuration files and all that doesn’t seem attractive when MAMP Pro let’s me switch PHP versions on the fly in about 10 seconds.
I haven’t lost touch with the original inspiration for this brain dump: profiling. As I was examining the tools baked into things like VVV I noticed something else that quickly became a hinderance. It again revolves around the fact that I’m piggybacking WordPress, not writing my own application from scratch.
In my limited research, I haven’t found a way to effectively limit the profiling aspect of these tools to focus on the code I’m writing instead of the entire request as a whole. If you’re a cachegrind or xhprof expert I would love to learn how I can limit my profiling data to a specific plugin or theme, or even a class itself. While the ‘full stack’ data is arguably more important in some regards, I simply don’t have control over the vast majority of a WordPress request from start to finish. I do, however, have full control over the code I’m writing. I want to make that code more performant, and I think something like this is going to be my starting point.
For WordPress veterans in this discipline: any tips?