At the End of 2012 I had my first contact with a C-based PHP frameworks, namely YAF. Coincidently, some day afterwards Bruno from phpmaster.com pointed me towards Phalcon - a more modern interpretation of the same idea. So I was hooked.
Why it is a good idea
What happens when you handle a request in a PHP (MVC or otherwise “bloated”) framework? In short: quite a lot before it reaches your actual (business) logic - and quite a lot afterwards as well. Every frameworks handles this differently, so let’s use the Symfony2 application flow for an example:
- The request comes in and is parsed
- The request is handled by the Front Controller
- The Symfony2 kernel converts the request into an object, pipes it through it’s routing and hands it over to an controller
- Your controller action is executed
- The response is standardized, piped through the view generation and printed out
These short five steps include a lot of class inheritance resolution and component loading. Most of any of these probably result in
include calls, which at least perform a
stat call on a
.php file (ok, this can be circumvented but comes with a downside) which costs I/O. If you don’t use opcode caches (or the files are not cached, yet) the source code is loaded (more I/O), interpreted and compiled into byte code (+CPU cost). If you have an opcode cache (and the file is already in the cache and has not changed), the byte code can be directly used. Anyhow, now the byte code is executed and voilå: your response is printed.
This is of course not any different with C-based frameworks - for your own code, that is. However, the majority of the I/O and CPU used in each request is highly likely consumed by the framework core itself. The more features the framework has, the more code it has and the more overhead of I/O and CPU it utilizes (even if you don’t use all of the features for any given request).
And here is where the C-based frameworks can play out their strengths: All the core code is already loaded, when the request is handled! It is loaded as an extension at the startup of your PHP runtime. This reduces at least the average I/O utilization massively, as no core
.php files have to be checked and loaded at all. This is a huge benefit, especially in I/O-weak environments, such as those based on network storage.
The other at least as big advantage is of course the pure speed of executing compiled C code vs PHP byte code. One, if not the major reason, for this is that PHP is weak/dynamic typed while C is strong typed. This basically means that PHP determines the type of each variable in each expression (eg
$x = 3; $y = "4" can be used in
$a = $x + $y; $b = $x . $y; and are interpreted as different types in each case).
And last but not least: the memory footprint of the pre-loaded C code is smaller. In a time where you can buy 16 GB RAM for about €100 this might not be such a big deal, but resources are resources and it still costs you more power.
In summary: C-based frameworks have a huge benefit in terms of resource usage (I/O, CPU, memory) and can be much faster than any pure PHP every could become.
Why it is a bad idea
As I became aware of those C-based frameworks late last year, I soon fell in love with the idea. However, there are still some downsides of which you should really be aware before migrating your production website ;) ..
Let’s begin with the obvious: PHP developers using a pure PHP framework can deal with problems / bugs of the underlying framework they use. They have the PHP skills for this, or at least those skills aren’t too far out of their reach. Building your PHP code around a C-based framework takes away this possibility. PHP developers are not necessarily good C developers, that is if they are C developers at all.
Next is community size: Sure, there are lots of C developers and lots of PHP developers. However, the amount of intersection isn’t that huge at all. I think it is not too far fetched to assert that there are there are far less of those than the amount of devs each “regular” PHP framework could (and the big onces do) produce. This, of course, has the expected side effects: Less people available to carry on when core developers loose interest. Less eyes on the code resulting in higher possibility of errors. Less already trained devs available for hire, if required. Naturally, a small and dedicated team can also be a huge asset and large communities can slow the development down and decrease code quality (“too many cooks spoil the broth”-effect).
Upgrading is also an additional problem. You can update the core of a “regular” framework by replacing all the files of the framework (simplified). If your framework is implemented in the for of a PHP extension, you need to replace the extension and restart the PHP runtime.
Finally: The biggest motor PHP’s success as the most widely used web language is (imho) the general availability of PHP interpreters in shared hosting based on the the simpleness to setup a PHP environment. As long as the specific C-based framework you want to employ does not have a large install base, and currently neither of the mentioned has, your hosting possibilities are heavily restricted.
I think C-based frameworks are a great idea. Competing against all the other web development languages, the incredible performance gives PHP a huge edge, if speed is of the essence. Both, Phalcon and YAF are quite mature and I see no reason not to use them in production. Personally I am a big fan of Phalcon, YAF seems a bit antiquated to me.
Sure, the availability of developers is an issue: There are of course more developers who are familiar with Laravel or Symfony than there are for Phalcon (or YAF). None the less, MVC is MVC, PHP is PHP, it’s not that hard to adapt for an interested dev.
Also availability in terms of hosting is a problem. I am confident, at least for Phalcon, this will change (shameless plug: did I mention we are providing Phalcon and YAF now?) and it vastly depends on whether it is requested from the providers or not - so basically up to you, anyway.