CI-based Web Sites Performance

[eluser]Edemilson Lima[/eluser]
http://en.wikipedia.org/wiki/Optimizatio...o_optimize

Hmmmm... Why does it rewrite URLs?


In time: I would like to see more people here answering the questions I asked in the first thread. It gives me a better insight about CI performance.

[eluser]Lewis[/eluser]
[quote author="beemr" date="1202850961"][quote author="Lewis" date="1202617719"]For example, using CI a result-set of 500 is returned, which is looped through by the database class, then my model to apply some formatting, and then the form helper to create a dropdown. That's 3 times, when it can all easily be done in one.[/quote]
I think the problem with progamming that holds speed as an ultimate goal is that there is the temptation to do it all in one go. That can lead to some rigid, linear processes that don't leave many openings for others to get involved or even to take over.

Web work is simply too multifaceted yet to safely pursue speed for its own sake. A little separation of labor goes a long way towards keeping a site live versus speed gains otherwise, even when doubled or tripled. I like the balance CI draws between speed and separation. Back when Java and .NET were going at it (I presume they're still fighting, but who's watching?), .NET used to trump its speed. It turned out that the advantage was mostly achieved through stored procedures on the SQL Server. How would you like to go begging your SQL admin everytime you wanted to add a new feature to your web app?

That being said, I do have to admit that every time I find myself making a second loop, I simply turn my first result set into a more complex object just to get rid of the extra loop. A small bargain with the devil, I think.[/quote]

I agree to a certain extent, but please tell me how

foreach ($query->result_array() as $row){:

is any more "usable" than:

while ($row = $query->fetch_array()){

and is worth looping through results twice? It doesn't bother me, I stopped using CI's database class when I found out that when it gets a NULL value it treats the array key as pure MySQL (which can cause havoc!) but I still think you should at least let people know about it. I just can't believe how it's used in the documentation to loop through. Yes it's a great little function for getting the result straight in to an array to pass to something else, but not to then stick straight in to a foreach query.

All the next_row() etc. functions run result_array() to get the cached version anyway so there's absolutely no reason not to let people use fetch_array().

There's a fine line between speed and usability and this just isn't needed.

[eluser]Edemilson Lima[/eluser]
The problem is not only run the loop twice but also spend more memory to store the results in arrays. $query->result_array() and $query->result() could free the results from memory, but it doesn't, because if it does, you could use $query->result_array() or $query->result(), but never both. So you stay with two copies of every result set in memory.

I do prefer that my models only return the result set from the queries, so I can loop through them directly in my views. Less loops and less used memory means more performance.

[eluser]Derek Allard[/eluser]
Some great discussion here.

I don't really want to step into the topic at hand regarding looping results (I will remain silent on this issue until I have time to properly consider it), but I did just want to say one thing.

It doesn’t bother me, I stopped using CI’s database class when I found out that when it gets a NULL value it treats the array key as pure MySQL (which can cause havoc!)

Its true that older versions of CI did this, but that hasn't been the case for the last 2 versions, unless you've discovered a new bug.

[eluser]Lewis[/eluser]
Ah I see. I think I'm on 1.5. But I've customised it so much its structure is completely different so upgrading would cause more hassle than it's worth for me. It's easier just to watch the changelogs and fix them myself in my own version and then steal CI's fancy new libraries. Although I thought the NULL problem was intentional to allow you to do 'raw SQL here' => NULL?

[eluser]Edemilson Lima[/eluser]

But I’ve customised it so much its structure is completely different so upgrading would cause more hassle than it’s worth for me

This is a kind of thing I will never want to do. Extending the core is fair, but hack it, I don't know if worth the price. Better if things are natively supported and are documented, so everything I do will be easily understood by other developers.

[eluser]Elliot Haughin[/eluser]
Well, I decided that when it comes to optimization, the numbers speak for themselves...
So, I decided to do a little study into CodeIgniter Optimization and Scalability, and the numbers really do speak for themselves this time!



So, take a look at this post...

Some things to note: * If the controller had have been more complex, I imagine the numbers would have been drastically different (namely memcache performing better in comparison).

But, this serves as a good overall test.

[eluser]Edemilson Lima[/eluser]

Code:

First off, let’s change:
foreach ($query->result_array() as $page):
to:
$pages = $query->result_array();
foreach ($pages as $page):

These two above are almost the same thing.
Could you benchmark the change below for us?

Code:

while ($page = $query->_fetch_assoc()):

[eluser]Michael Wales[/eluser]
The reason he chose to move the result_array() call outside of the loop is because PHP runs foreach conditions upon every loop. A call to a function is slightly worse, performance wise, than a variable retrieval.

So, if a function call takes 1ms longer than a variable call, you can definitely see the benefits across 20-30 items you are looping.

I would assume a call to _fetch_assoc would render similar results. The speeds would be comparable to the call to result_array() but you will always be faster references the variable rather than a function call.

[eluser]Edemilson Lima[/eluser]

I would assume a call to _fetch_assoc would render similar results. The speeds would be comparable to the call to result_array() but you will always be faster references the variable rather than a function call.

I agree that referencing a variable is faster than a function call. But, that function call is already done by result_array(). So, it will not change the overall performance. However, the loop will run only once and data will not be copied to an array. This means less CPU cycles and less memory usage. I bet that the benchmark with my example is even faster. Also, as a suggestion, this benchmark could check the memory usage in each test.