Thoughts On PECL Frameworks
But It's High Performance!
In all seriousness, this benchmark proves nothing. It's very tempting to say "well, the framework itself has less overhead, so that must be good, right?"... But that's also a very dangerous assertion. The fact of the matter is that the framework's overhead will likely be far outweighed by your application's overhead. And that will likely be far outweighed by your application's external dependencies (database, filesystem, 3pd REST calls, etc).
What You Give Up
The importance of a framework or library is not the amount of overhead that it has, but what it gives you for that overhead. There is no free lunch in this world. Everything is a tradeoff. The additional efficiency that a C based framework give us comes a a very significant cost:
I do know C. But knowing C and PHP's PECL extension mechanism, I'd rather read PHP. That's not to say that I couldn't read the C code to figure out what's going on. Indeed I could (and have). But when I'm writing PHP code, I'd rather not have to switch my mental model back and forth from PHP to C to figure out what's going on.
Thanks to tools like gdb, it's pretty easy to debug C code. The problem is that we're not debugging C code, we're debugging PHP code written on top of C. While this does present its own challenges, having the framework portion in C means that XDebug is all but useless for figuring out what's going on. Now, you're stuck having to debug PHP code with both XDebug and gdb. And having done exactly that before, all I can tell you is: have fun...
With a traditional PHP framework, any application that you write is going to be largely portable to almost any server configuration. But with a PECL based framework, you're stuck with only being able to move to supported environments (for that PECL extension) where you have root access to install PECL extensions. While in many cases this may not be a huge issue, it's something to think about.
If your (or your team's) core competence is not C, using a PECL based framework can be suicide for a long term project. The reason is that you're pitching the success and support of your application on a tool that you cannot fix if you wanted to. So when bugs crop up, you're stuck asking the community for help. While that may not seem like a huge issue, imagine explaining to the CEO of your company that your site has been broken for two weeks because you couldn't find anyone to fix the bug.
With a PHP based framework, if all else fails you can go in and fix the issue. In fact, this is a lot more common than you may think. Not to mention that this is usually how bugs get fixed in a large project anyway (someone fixes the bug, and submits a patch to core). At least with a PHP based framework this option is open to you.
What You Gain
But I Have A High Traffic Site!
Even if you do, this type of a gain is going to give you minimal results. Look at those benchmarks again a little bit closer. You can see that the slowest framework (Symfony 2) serves each page view in 40ms while the PECL based framework serves each view in about 2ms. Our gut instinct points out that it's a HUGE difference. And it is. But that's 38ms per request. Let's even say that your application resolves in 50ms on top of the framework (let's say it's a bloody fast app). So we're talking 90ms vs 52ms. Still a big difference, right?
Not really. With numbers that small, you'd need traffic levels on the scale of thousands of requests per second to see any kind of meaningful cost savings. 1k requests per second equates to 86 million requests per day. If we make the numbers more realistic, say 200ms for the application layer, the result is even more stark. 38ms out of a 240ms response is 16%. That's large, right?
Saving 16% off your front-end server costs will wind up saving you almost nothing. Think about it for a minute. Let's say a server costs you $200 per month. To see a gain from 16% savings, you need at least 7 servers. And with 7 servers, you just saved a whopping $2400 per year! Good for you (especially considering the cost of the added developers that you might encounter due to the lower level code)!
Note that I'm only saying this about using full blown frameworks written in C. Not one-off libraries. Not PECL extensions in general. Just full blown frameworks (which you already know my opinion on)...