Juozas devBlog

Zend Framework is always considered as being the slow/bloated one. I don’t think this is right, so I decided to prove that it’s not correct and in fact ZF is as good as other frameworks are. This post doesn’t cover any benchmarks though; this is more like a architecture review and some misconceptions disproof.

Before we go any further, let’s check with Wikipedia:

Software bloat is a term used to describe the tendency of newer computer programs to have a larger installation footprint, or have many unnecessary features that are not used by end users, or just generally use more system resources than necessary, while offering little or no benefit to its users.

So what I need to provide is contra arguments that Zend Framework doesn’t do those.

“Large installation footprint”

25.8 MB and 2338 files. This is how much ZF weights and this is usually quoted as the main factor of bloatedness. First of all, 25.8 MB is a joke – full application takes maximum 50 MB. So unless you want to squeeze in 100’s of projects into a shared hosting, size of ZF shouldn’t matter at all. Price of hard-drive and RAM (for APC caches) is so low nowadays, that I don’t even remember last time I checked how much space my project takes up.

Same applies with files count – why would anyone even care how much files it has? As you probably know, PHP doesn’t compile your project into one binary, thus making it a big file. What it does, is it loads external code using include/require statements. Hence, from those 2338 you usually going to use around 300 (based on my tests). One can argue that this is still a lot of files, but this big number of files comes from ZF extensibility. A lot of functionality is separated into plugins, adapters etc.

“Unnecessary features”

ZF has massive amount of functionality: starting from web framework components and finishing up with services classes (I have written more about this here). There is a big chance that you are not going to use all of them, but because all components are decoupled (as much as possible) and as mentioned above, you don’t even notice them if you don’t include those files.

I’m one of those people who think that ZF has too much components, but this is rather my own personal preference rather than a problem. Nevertheless, I haven’t used only a few of available components as once you need something, it’s always very quick to just use it. No need to download anything more or look for available components. For serious components like Doctrine, you probably want to look around, but just for some regular code Zend provides all required features.

“Use more system resources”

This one is hot topic in ZF world. But the point here is that “features = slow”, especially in PHP. This happens because PHP as a language is not that fast and as you start adding more features and code, you get slower code. This where framework’s benchmarks are born, but as Pádraic mentions in his post about benchmarks:

To create a positive benchmark, you need to understand that all frameworks were born as festering piles of unoptimised stinking crap. They were all born bad and get worse with age. This sounds quite sad, but actually it’s an inevitable compromise between performance and features. It’s also a compromise between performance and ease-of-use

It’s inevitable to provide those features that ZF provides and still work faster than other frameworks. So considering the speed of development you need to know how much performance you actually need. Maybe rapid development is much more important? At least it’s for me, and by sacrificing some tenths of a second I can roll out projects in a few days. And as “bloated” definition states, something is not bloated if it provides benefits while using more system resources.

How to make it not bloated?

If you still consider ZF as bloated framework, let me give you some ideas how to make it work for you. First of all – profile, profile, profile! I keep mentioning this every time I talk about performance, but don’t judge performance of something without actually knowing why it’s not performing well. Xdebug helps here as it can provide profiling data, which you then can use to detect slow parts of code. From my experience this is usually I/O – DB calls, file reads etc. Get rid of those and you have some decent performance increase.

A lot of other performance factors come from knowing how framework works internally or really reading manual. For example Zend_Application is kind of slow, but it can be easily optimized by just getting rid of it. But this is only needed if you are running very big application, where every millisecond of execution matters, for normal application you’d hardly get any benefit. This is very ZF’s decoupled components start to shine, as you can just use those which work well and add some special sauce for other parts.

Conclusion

I use Zend Framework extensively, so I’m biased a lot here, but having this much of experience, I can at least judge it objectively (up to some degree). And what I can say is that ZF is not bloated, it can be slower than some other available frameworks, but widely popular method to judge its performance by the number of files it has is just wrong. Of course it’s not the easiest framework to get working with (and get it to perform efficiently), but don’t get put off just by archive size it comes in.