So, I’ve noticed quite a few frameworks and one CMS (drupal 8) using Symfony framework’s httpKernel. Although I want to wait for PHP 7 to get closer to release (and therefore get a better picture of the changes to the engine internal API) I’ve been mulling the idea of translating the most frequently used Symfony components into a C++ PHP.so library. If I start on this I’ll definitely need some help. Hence project Rhapsody.
Rhapsody isn’t a replacement for Symfony - it’s a optimized parallel. Rhapsody components have the same name as their Symfony equivalents and therefore need to be 100% compatible - the only difference being speed. The only big advantage Symfony will have is the code, being PHP, will be easier to inspect. Rhapsody, being compiled C++, will be very much a black box.
Translating all of symfony into C++ would be a bit much - so I’m really just thinking of doing this for a handful of components specifically
httpKernel
httpFoundation
ClassLoader
Of these I’m most keen on the class loader extension since it may be able to be built to run in two modes - normal mode being 100% compatible, and extended which would allow it to pull tricks a PHP library would not be able to while still remaining compatible – the only idea I have here is providing a bit of functionality PHP should have had a long time ago – assert remove, which would completely pull assert statements out of the incoming class code before compiling it.
I think it’s a bit of an overkill of a project as it would be very difficult to maintain and bugfix after a while. I would rather suggest Zephir instead of C++, as it’s designed for that exact purpose while remaining PHP-dev friendly. It’s “almost PHP” (official 1.0 release is coming in a few months but it’s as good as ready now) but compiles down to C, and is what powers Phalcon 2.0 (due for release this week).
I really like the idea of compiling commonly used components for the benefits of speed etc, which is why I’ve been playing around with Zephir a fair bit. However, the “Phalcon” problem raises it’s head a little - the visibility of the code and the correspondingly increased difficulty in deploying fixes and updates to the libraries.
Short of convenient provision of apt/yum style repos, “composer update” kinda has the advantage.
Wouldn’t a JIT compiler make this kind of effort sort of superfluous? Although there hasn’t been any definite plan made, I thought PHP7 would be heading towards one. If anything, I would have thought a JIT compiler is what everyone needing more performance out of PHP would want to have. It requires no extra language like Zephir. It requires no extra “waiting time” for compilation, which means it doesn’t get in the way of development speed. It doesn’t have the issue of deploying fixes and updates to libraries.
Because of those advantages, I would think the PHP developer community would want to should push for this, but it seems (like so often) there is a split in opinion on the necessity of a JIT compiler. I did a poll in two different G+ PHP communities and got these results from about 150 devs.
Some say, PHP is fast enough, when say an opcode cache is used. After that, then other systems become the bottleneck, like the database. I still say JIT is the ultimate “end” to getting PHP at least as close to Java or C++ in terms of performance. One other advantage I am personally interested in with JIT is the savings in RAM.