The title of this article could have been « The definitive guide to (not) responding to speed benchmarks and framework comparisons ». We regularly see framework benchmarks pop up somewhere on the net, comparing symfony to other frameworks, either in PHP or in other languages. The conclusion of some of them is « symfony takes more time than other frameworks to display a "hello, world", which makes it unsuitable for real-world web applications ». Comments on these articles are mixed, from the complete troll to the constructive discussion. But whatever is said on the subject, the question always reappears, and it seems that people are reinventing the wheel each time they see such conclusions. Contradicting this kind of statement requires some thinking, so get prepared for some reading.

Symfony is not slow in the meaning of "not optimized"

If some benchmarks show that symfony is slower, jumping to the conclusion that symfony is not optimized is a big mistake. I'd say that people who take this shortcut are either way smarter than us, or they don't know what profiling is, they didn't look at the symfony code, and they can't make the difference between efficient code and a bottle of beer.

The coding practices of symfony developers come from the experience of numerous web applications developed over almost 10 years. We have a quite accurate idea of which code is slow and which code is fast, because performance has always be one of our clients' main requirements. We tested many implementations, we read a lot about the current best practices, and we tried to put the best of what we've learned so far into the symfony code. So for instance, you will not find this code in symfony:

for ($i = 0; $i<count($my_array); $i++)

instead, we try to always do:

for ($i = 0, $count = count($my_array); $i<$count; $i++)

This is because we know it makes a difference.

How do we know it? Because we measured. We do use profiling tools a lot, on our own applications as well as on symfony itself. In fact, if you look at the symfony code, you can see that there are numerous optimizations already in place. And if you use a profiling tool yourself on a symfony application, you will probably see that there is no way to significantly optimize symfony without cutting through its features.

Of course, there might still be a lot of small optimizations possible here and there. If you find some, please open a ticket in the symfony trac system, and we'll add it to the trunk as long as it doesn't break BC or require a third-party component.

Symfony's speed is a choice

If symfony is well implemented (or so we think), then its speed is just the sum of the individual speeds of all the features it includes. Or, to put it differently, Symfony's speed is the consequence of a series of choices that we made to decide whether a feature should or should not make it to the core.

These choices were not easy to make, and you could easily discuss them. Symfony results from a vision of what would the perfect tool for developers, based on our experience. For instance, we decided that output escaping should be included by default, and that configuration should be written preferably in YAML. This is because output escaping protects applications from cross-site scripting (XSS) attacks, and because YAML files are much easier to read and write than XML. I could name similar arguments about security, validation, multiple environments, and all the other features of symfony. We didn't add them to symfony because it was fun. We added them because you need them in almost every web application.

Note that even if these features exist in symfony, you can always deactivate them, because of the great configurability of the framework and the ability to override its classes.

For each choice, we carefully weighed the benefits in functionality and ease of development, and the penalty in performance. Symfony embarks a lot of features activated by default (when you compare it to other frameworks) because we think that the cost of development is more important than the cost of hosting. It is very easy to add a new server to boost the performance of a website, it is very hard to add a new developer to an existing project to make it complete faster.

Benchmarking the speed of a "Hello, world" script makes little sense

So a framework has a certain speed because it has a certain set of features packaged by default. If you take this idea the other way around, you could conclude that the fastest framework on earth is no framework at all. Some very well-known developers actually defend this point of view: Using plain PHP will make your application way faster than using a framework. Nevertheless, none of the framework benchmarks actually compare frameworks to a naked language. This is because it doesn't make sense. If frameworks exist, it is not for the purpose of speed, it is for ease of programming, and to decrease the cost of a line of code. This cost not only consists of the time to write it, but also the time to test it, to refactor it, to deploy it, to host it, and to maintain it over several years.

It doesn't make much more sense to compare frameworks that don't propose the same number of features. The next time you see symfony compared with another framework on a "hello, world", try to check if the other framework has i18n, output escaping, Ajax helpers, validation, and ORM turned on. It will probably not be the case, so it's like comparing pears and apples.

Also, how often do you see pages displaying "hello, world" in real life web applications? I never saw one. Web applications nowadays rely on very dynamic pages, with a large amount of code dedicated to the hip features dealing with communities, mashups, Ajax and rich UI. Surprisingly, such pages are never tested in framework benchmarks. And besides, even if you had a rough idea of the difference in performance between two frameworks on a complex page, you would have to balance this result with the time necessary to develop this very page with each framework.

So the best way to display a "hello, world" in terms of performance is probably:

<?php echo "hello, world" ?>

If your application reduces to that, obviously, you don't need a framework. Otherwise, you need to base your decision on another type of benchmark.

The speed of a framework is not the most important argument

Said in a provocative way, the conclusion of the previous section could be: "symfony is slow on purpose". We could even defend this, because the raw speed of a framework only counts for a tiny share of the performance of an application as perceived by the end user, and as one argument between a lot of others in the choice of a development tool.

The performance perceived by the user depends on the raw speed of the framework user in the backend, but also on many other factors. The number of assets (images, CSS, scripts, etc.) to download for a given page can affect the download time dramatically. The user's bandwidth and number of possible concurrent requests are often the most important bottlenecks in Internet communications. The number of database queries and the quality of the indexation of the database involved can also impact performance a lot. The speed of the components used by the host (database vendor, op-code cache, disks, network interfaces, etc.) are also an important factor. These are just examples, but the point is that a properly configured platform, using a CDN, high performance components, carefully tweaked and well monitored, is much more important for the user's feeling of speed than the raw speed of the server-side scripts.

And between two framework alternatives with comparable speed, a company will look at other factors to make a good decision. The quality of the documentation, which is directly proportional to the number of good developers available on a framework, is decisive. The cost and availability of developers for a given language, for instance, push many deciders to give up Ruby on Rails or Django for PHP frameworks. The difficulty to host and monitor these solutions is also a key factor in the balance, since fast cgi is not as stable as mod_php. In addition, clients will have to maintain the applications you develop for them, and they will need developers for that. If you elect a not widespread solution, you may loose some of your clients.

Let's finish by saying that in most cases, symfony does not compete with RoR or Django. The choice is often between symfony, .Net and Java Struts, because these are the real alternatives for professional developments.

Conclusion

Dismissing symfony because the speed of a "hello, world" test is not as good as with FooBar framework is a mistake. Raw speed is not the key factor for professionals. Cost is the key factor. And the cost of development, hosting and maintenance of an application with symfony is less than what it is for other solutions. This is untrue if what you need is a simple CMS, a weblog, or a script that says: "hello, world". But in those cases, you don't need a framework.

If what you need is a reliable, documented, full-featured, well supported, largely adopted, well coded, free and extensible framework, then go for symfony. Of course, symfony has some defaults; it is still young and is not funded by a billion dollar company. But "hello, world" speed is not a default that you should pay too much attention to. Besides, symfony is optimized as much as possible for all that it offers.

And if you need a second opinion, because you can't believe what the creator of a framework says about his own framework, perhaps you could listen to other companies who did choose symfony. Yahoo! picked symfony for a 20 Million users application, and I bet they measured the speed of a "hello, world" and other factors before making that decision. Many other large companies picked the symfony framework for applications that are crucial to their business, and they continue to trust us.

Published in #Symfony