The following question appeared out of the blue in #yii on Freenode in September 2014:
hi i have started working on yii framework... and other pople have been continuously telling me that its a bad decision and using yii will slow down the site and performance will not be good, better go for core php...any of your thoughts will be great help..cheers
There is no way to really answer the question because it depends so heavily on the specific application, the technologies involved and their deployment. Plenty of attempts have been made to benchmark different MVCs but the results are usually perfectly irrelevant to any given application. It would be a foolish mistake to think that data from, for example, TechEmpower's Web Framework Benchmarks would predict relative performance of your web site.
One criticism of using an MVC framework (MVCF) that tends to stick better than others is one that Rasmus Lehrdorf (who has spent a good deal of his career trying to persuade people that all PHP frameworks suck) has been making for years: Ordinary webapp operations require loading very many classes when implemented in the MVCF and very few when written in plain PHP. Lehrdorf typically demonstrates it with graphs of class loads required for simple example web pages. But what does this mean in practice? And is it a problem?
If you were loading each of those classes from the filesystem every time a page request needs them, that might potentially lead to a problem in a high-traffic web site. But nobody does that in real life. First, we use an opcode cache, such as APC or opcache, so that the classes are ready in their compiled state in memory when we need them. Second, when we need to, we combine the framework classes we need into one PHP file using a build script before deployment so that loading the entire framework involves only one filesystem operation from the autoloader, after which everything is available from the opcode cache. So class loading is really a non-problem for most applications.
If merging PHP class files and using an opcode cache isn't efficient enough given your hardware budget then you must have a very heavy traffic load. If this is the case, you won't solve the problem by abandoning MVC because that still leaves you with PHP. For high-performance applications you should be looking elsewhere than PHP.
The original question presumes that performance of the web application depends on performance of the PHP code. Very often this dependence is actually rather small.
Commonly it is the database that constrains webapp performance. Consider the amazing innovations in database technology we've seen in the last few years. That happened because that's where the bottlenecks were. Performance is a big deal in databases. We now have whole new classes of database server and, even more impressive, they've been deployed. At the same time, much innovation in programming languages addresses problems of programming in the large rather than performance. The cost of maintenance in large projects with a long life are very high and completely swamp the marginal performance gains that might be available.
So even if not using an MVCF could give a performance boost to the PHP scripts (and I'm skeptical) then this would normally be premature optimization because PHP processing will most likely be a small part of your performance problem.
When you choose to not use a good MVCF, such as Yii, and choose to write in straight PHP instead, what do you gain and what do you lose?
The gains are nearly always claimed to be performance. But as you see from the above, I am skeptical. I would say that the performance gain is usually imaginary.
The losses, on the other hand, are quite clear:
-
Time. Writing a webapp in a good MVCF takes less time -- a lot less. If you did not already understand this then you were not competent to ask the original question.
-
Extensions. The most widely used MVCFs have a nice collection of OSS extensions that people have donated to the community. Many of them are quite mature and rubust because they have benefited from the collective experience of a great many users.
-
Organization. MVC provides a consistent organization that allows many programmers to work on different parts of the same project and the whole thing comes together quite easily. The lead developer has to lay down the guidelines for style and coding standards and ensure that any consumer of a model's API is OK with its design. Other than that, developers can write their controllers, views, stylesheets, client scripts, widgets and shared components without stepping on each others' toes all the time.
-
Maintainability. MVC has proven itself to make the long term maintenance of a webapp's code quite a lot easier. For me, this is the killer argument. I use MVC first and foremost because, in the long run, I can't afford not to.