On 20 January 2014 19:03, moderndeveloper [via Zend Framework Community] < [email protected]> wrote:
> Marco Pivetta wrote > mac_nibblet (Antoine Hedgecock) has already tried zephir extensively to > port the Zend\EventManager component for ZF3 as a C extension. The result > was interesting, but still not good enough to justify the pains of > debugging C code (yes, you still need to go into C code when using > Zephir). > The segfaults and bugs encountered were discouraging in my opinion. > > Well, testing pre-alpha can have that effect. Just went alpha 1 on Jan. 17. > Agreed, but I'm used to work with pre-release software most of my time - the number of added troubles is simply not worth it for now. > > Marco Pivetta wrote > Results were much better with HHVM and native PHP code. > > Is there somewhere that shows the results of this test, or was the > EventManager never able to get up an running on Zephir? I know that HHVM is > rocking fast, but how much faster? Could it actually make ZF2 faster than > Phalcon? Will the intl extension be included soon? > The EVM was correctly built in Zephir, and Antoine got HHVM 2x faster than it - results are on his computer though, I only saw them personally at ZendCon Europe, so maybe he can try and release them. Yes, HHVM can make ZF2 faster. The Intl extension is almost complete in HHVM as well. > > To the original poster, I've used ZF2 and Phalcon. Just to point out, > Phalcon and Zephir are two different things. They are both being written by > the same team, but you don't have to use or know both to use either. > Phalcon is the framework just like ZF where you write plain-old PHP to > create your application. The speed advantages come in that the framework is > pre-compiled into C and loaded as a PHP extension. Your code still uses the > regular PHP JIT compiler when run, so if you write slow code, it will still > be slow code in a supper fast framework :-) Aware of all this, but the argument is quite moot if the execution time is not swallowed by the framework (which is not the case for me, for example). Fixing architectural problems brings more performance gains than banging them with a compiled version of the vendors. > Zephir is the intermediate language where you could, theoretically right > now, write ALL your userland code and have your entire application compiled > to C and installed on the server as a PHP extension. I haven't done this > and probably won't even try until Zephir is in late beta. > Yes, this is what has been done so far - it's just not worth it and it reduces the number of people that can work on your code, as well as portability. > > There are advantages to both frameworks. > > *ZF2 advantages* > * ZF2 has a very large developer community using and updating the > framework. > That's true for other FWs as well > * ZF2 has a company behind it pushing dev forward. > * ZF2 has many more helper/utility classes included in the full package to > help you "do the right thing" in your code. > That's what a focus of a FW should be on - fixing what the users of the framework usually don't fix (security, parsers, complex DSLs, some architectural decisions, etc) > * Packagist has tons of pre-made modules for different problems. Some of > them rather good. That's true for packages for PHP in general, not just ZF > > *Phalcon Advantages* > * Speed > moot - fix your architecture first > * Speed > moot - fix your architecture first > * Did I mention speed? I haven't seen a benchmark yet that shows less than > a 10x (not 10%, 10x) speed increase over ZF2 even for the simplest Hello World script. The Phalcon micro framework<http://docs.phalconphp.com/en/latest/reference/micro.html> is > even faster. Did I mention that it's moot? Fix your architecture already! If you are bombing the framework at every request on performance-sensitive apps and you are not scaling or distributing things correctly, then you are doing it wrong. * It's much less "configuration as framework" while still allowing for a > full dependency injection/services/events (DISE) style applications. > ZF2 is also like that when using it "standalone" (without skeleton app) > Marco is right in that, if you want to get into the internals of Phalcon, > you need to be a C programmer. If you are the type of developer who just > wants to use the framework and just add bug reports when something is > wrong, it's not that big an issue. There are only two main developers that > do 99% of the programming, so you could have concerns about project > longevity, etc. Then again, the same could be said for any software. They > are extremely active at the moment, with actual bugs getting fixed in > Github pretty fast. Feature requests do take a bit longer if they are not > simple "add a getter/setter/property to X class please" stuff. > That is perfectly fine, I admire their work, but as a company, I can't have a business critical process rely on external C developers. If a critical bug is met, I must be able to patch it locally in minutes and then submit the patch in a PR - I cannot have my developers learn both PHP and advanced C to handle these problems, it's simply not possible. > Being a smaller community, there is a little less "if you don't do it this > way, you're doing it WRONG!!" kinda holy wars going on, but that's a very > personal opinion. That is what a framework is all about - bringing in good practices and techniques. If a framework is not doing that (for its own scope) then it's not worth using it. Actually, every library should encapsulate the problem it tries to solve in a way that makes it "less of an abomination" for the end user. Therefore, yes, it is all about getting rid of the "wrong" ( http://www.youtube.com/watch?v=WrjwaqZfjIY ) implementation by the user, and leading him to the right path. I personally do not feel there is real utility to creating a service, > mapper, plain-old object, and interface for that object, with all the > accompanying config, for every single thing I need to pull out of the DB. Well, I'm part of Doctrine's team, so I simply will hold my fingers from replying to this, since we may continue discussing for AAAAAAAGES. > Phalcon's included ORM/ODM is lightning fast and very serviceable. The > devs have Phalcon running as fast in Zephir as in C, though I think some of > Phalcon will stay in C for speed purposes. > That is the same problem we noticed with YAF > TL;DR - Both frameworks are good, but aimed at different crowds in that > you go with Phalcon for raw speed, and ZF2 for most other reasons. The rest > is personal preference on how you like to build apps. I would give one of > the sample apps <https://github.com/phalcon/vokuro> a whirl for Phalcon > just to see if you like how things are structured. > Raw speed is useless if you're building it wrong (IMO) - doesn't mean that if you use Phalcon you are necessarily building it wrong, though ;) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ -- View this message in context: http://zend-framework-community.634137.n4.nabble.com/yaf-and-phalcon-tp4661414p4661493.html Sent from the Zend Framework mailing list archive at Nabble.com.
