Yesterday evening our beloved @t3popcorn accoutn did post this tweet https://twitter.com/T3Popcorn/status/582994007858368512. For all that cannot see it as the account is private: It has a link to https://github.com/kenjis/php-framework-benchmark in it and asked why Flow isn't part of the benchmark.
I then checked out the repository and tried to get Flow benchmarked as well and after some minutes it already worked quite well, though it just ran in the development context. But what exactly did I do? I just install Flow in a subdirectory with this command: composer create-project --dev --keep-vcs typo3/flow-base-distribution typo3flow as stated in http://docs.typo3.org/flow/TYPO3FlowDocumentation/Quickstart/Index.html. At this moment of writing this command installs Flow 2.3. To test a real world scenario, I did a ./flow flow:cache:warmup before running the benchmark. So the first actual web request doesn't need to prepare the caches. Laravel does something similar as well.
The first results were hard to believe. The best framework so far could handle 17.000 requests in between 10 seconds. Meanwhile Flow managed to handle only 400 something. In the chart, generated by the benchmark tool I could hardly see any bar at all. Anyway, these results were flawed due to several different reasons.
Up to this point of time I didn't test Flow in the production context, so that was the first thing to adjust. To do so, I needed to change the index.php of Flow.
Another thing I did wrong, was to test the output of the welcome controller which not just returns a lot more bytes than the other test suites but added a whole html site with stylesheets, scripts and so on. To fix this I removed all the php code from the controller and did a simple return 'Hello World!'.
What I didn't see in the first place was, that Phalcon for instance threw a fatal error on each test. So beside the fact that it's a compiled C module for PHP and therefore is the fastest framework in the whole terstsuite anyway, it was amazingly fast due to improper rendering. Some other frameworks didn't work as well because of missing php modules like mcrypt or intl. To clear things up, I excluded these frameworks from the testsuite, so only frameworks with a proper Hello World! and a HTTP 200 response were benchmarked.
Something I didn't realize that evening, was that other frameworks were optimized for the benchmark. Symfony for example did remove/deactivtae all the unneeded components for this benchmark. I must admit that this is unfair, not just in comparison to Flow but in general. I'd like to see these adjustments removed to have a proper result. Anyway, not all frameworks were adjusted to best best at this particular test. Also it's easy to revert the changes and test the default configuration of each framework again.
With all adjustments made, Flow could increase the number of requests up to about 800. This time in production context, without template rendering or additional controller logic. So, the amount of requests doubled but were still very low.
One thing is for sure, there is not one single, right conclusion. You can have so many different looks at the data, it's impossible to create just one conclusion from it. But there is a chance to gather some facts instead. If we look at slim, which had the best results, we can see, that it really is a slim framework. You basically just connect routes to controllers or even just callback functions. So what the framework needs to do, is to resolve the route and exec a callback function that echoes Hello World!. That's damn close to just echoing that string in a PHP file. So, slim isn't made to be a framework for complex applications and that's ok. If we look at laravel, we have a pretty bad result as well. It's a lot better than Flow but also a lot worse than slim. That might be the case because laravel wants to be a full feature framework, just like Flow and Symfony do. Its purpose is not to be the tool for a mock page like slim could be. So, do we compare apples and pears here? If we compare Flow and slim, that's true. When it comes to Laravel and Flow you need to prove me wrong because I consider these both apples. Same applies to symfony and zend. So, the benchmark gives you a chart and the possibility to compare the frameworks you want to compare, nothing else. And that doesn't mean, faster is better, not in general!
So, what I talked about is purpose and that's pretty important here. Because whenever you choose a framework, you do it for a reason. And the reason why to choose a framework at all, is, that you need several functionalities you don't want to build on your own. If you focus on speed you might choose another framework than if you focus on security for instance. Well, what's the purpose of Flow, actually?
I assume that each and every framework is built for a reason. When someone came up with the idea of slim, he/she might have had the need for a lightning fast and slim framework that brings routing and basic mvc functionality. When Flow was built, people felt the need to create a new framework for the successor of TYPO3. But what was missing in the existing frameworks back then? To be honest, I don't know. But if we look at what makes Flow unique, it's definitely AOP and therefore the proxy class building. The question is, who needed this feature most. Neos, Flow itself or persons? The same question arises for each and every self made, reinvented wheel. Fluid for instance. Somehow we need to be sure, if this is really made to make Neos benefit or just to be a great personal experience. I simply want to know why all that stuff that has been built, needed to be built to make Neos a good project. Would it be worse without AOP or with Smarty as a template engine?
If we say, that Neos is dependent on Flow, and I don't mean the code base but the concepts here, we shouldn't compare Flow to other frameworks because then, its purpose is clear. It's made to be the perfect foundation for Neos. But why should the product be used for other applications, then? Marketing wise I don't see the statement of Flow to be just the perfect foundation for Neos but to be the perfect next generation framework for everything, so let's compare it to symfony and so on. And don't tell me I can't because it's just Neos' sidekick. It isn't.