I'm migrating my project from CodeIgniter 2.1.4 to FuelPHP 1.6.1, and I've seen a 400% increase of the page loading time. It went to 40~90ms loading time per page, up from 10~30ms.
I run this on a dual-quad-core server with lots of ram and a fast SSD, now I wonder why the load time increase?
Is it because I use ORM models to get things from DB ?
I also turned off auto_filter off in all views, which saved about 50%'ish in loadtime, but it's still quite high..
Any things I should be aware of that might cause the extended loadtime ?
That is very difficult to say without knowing what you've been up to, and what you've exactly comparing.
The CI core is very light-weight, so if you make something simple, it is bound to be extremely fast compared to more OO frameworks (which simply need to load and instantiate more objects). The Fuel core will also setup more, such as Config and Lang structures, even if you don't use it.
On the plus side, the Fuel core processing time is rather stable, doesn't matter how complex your application will get. CI's core will become slower as you use more features, especially if you start with extending the core, HMVC, and stuff like that.
ORM is definitely a factor, depending on what you fetch. As with any ORM, it's not made for bulk operations, and will have a substantial overhead for large resultsets, if only because it has to instantiate an object for every row retrieved, and if relations are involved, it will need to split the resultset and create objects for those records too. It also caches those objects, so you'll probably see substantial memory usage as well.
If disabling the output encoding on views (which in the standard setup is a simple htmlentities() call) gives you such substantial savings, my guess (without seeing the code) is you're fetching a lot of data, and sending it all to the view...
I can't say you should, but you could try and see if there is a (for you) significant performance difference. It will depend on the size of the resultset, I don't think you'll see much difference with 10 records...
You could always profile the request using xhprof, or xdebug/cachegrind, to see where the delay is.
We have someone specialized in profiling doing the same on the core on a regular basis, so we're pretty sure we're covered there.
Donate
