So regarding Zephir - since Phalcon 2 will mostly be written in it, will there be a performance hit when comparing Phalcon 1 and Phalcon 2, since the careful optimizations possible in C won't be possible in Zephir, or do you intend to normalize this and make them perform equally well, if not better?
I think that until Phalcon 2 be released (at least a beta) there will not be real possibility to accurately compare the performance difference between both versions. But as the team said in the blog post, in the long run the framework may become faster (they claim that some parts of the extension will still be written in C for performance purposes, and "Zephir will support call and use C-functions if necessary").
The plan is to keep performance as is or even make it better. That has always been the goal
Zephir will parse its code (the code generated by the developer) and in term "translate" it into low lever C instructions and compile it. In effect it will generate the same C code that Phalcon currently uses so performance will not be impacted. (that is assuming that the source code - the code that Zephir will use - has not changed).
Some parts of Phalcon 2 will be written in C since Zephir will not be able to help and if we develop those parts in Zephir we will lose performance.
Currently, despite being a C-extension there are a lot of dynamic features we have to deal with. When 0.x/1.x was designed, one of the highlights in the framework's design we had in mind was the possibility of being loosely coupled and allow users to do things like override any method, intercept method execution, add additional methods that read/update internal properties, etc.
Basically, the framework is ready to naturally accept any kind of external action from the PHP side, this makes Phalcon look like a pure PHP framework, reducing the impact that a C-framework could result in developers who are used to only PHP frameworks. All this ease and flexibility has a performance cost in 0.x/1.x. The truth is that we do not always want or need to extend phalcon's classes, hack or replace their internal properties or completely/partially replace them with our own classes.
So, Zephir will give the opportunity to produce more low-level code if a developer decide he/she wants to sacrifice flexibility (or doesn't need it at all) by getting more performance. The 1.x codebase is in fact, very high level because it tends to make everyone happy implementing all these features I mentioned above.
Another important topic is the fact that most of the current codebase is written with the intention of allow PHP developers to understand the code, readable code for a PHP developer is far from what can be done in C, Zephir gives us the opportunity to produce code less readable (in C) but more efficient in its execution.
The following parts of Phalcon will remain in C since their performance is better:
- Volt parser
- Annotations parser
- PHQL parser/cache
- Phalcon\Escaper
- Phalcon\Kernel
- Cssmin/Jsmin
- Some parts of Phalcon\Db that deal with PDO structures
Good stuff, thanks
Just piping in my $0.02, in about two hours today or so I was able to install zephir on my ubuntu box and start hacking some code into a namespace (migrating a hal-based api library) with some working stuff. So far it has been pretty easy (granted, fairly simple classes so far) to translate some php classes into zephir code.
For library type code I totally see how kickass this could be, Im pretty stoked to be able to hack a bit and have things available as a php extension.
Would you consider writing it into a tutorial and getting published on Sitepoint's PHP channel? I'd really like to push Phalcon and zephir out a bit more. Get in touch at [email protected] if interested