CI Memory Usage

#1
[eluser]tonanbarbarian[/eluser]
Some people may have seen me post before about CI and the amount of memory that it uses.
In fact you may think I'm a bit obsessed with it.
When you host a server that has numerous sites on it you become a little that way. Memory and CPU is always a resource worth more than gold in any hosted environment.

I was doing a bit of work on a project today and took a few minutes to test something and found some interesting results.

Firstly do not get me wrong, I think CI is the best when it comes to memory usage. But I have found an interesting tip to further improve it.

I had numerous libraries or helpers that needed to access the controller, so depending on which case it was determined how I gave them access.

In a library I typically did
Code:
Class Blah {

  var $CI=null;

  function Blah() {
    $this->CI =& get_instance();
  }
}
And in a helper I typically did
Code:
function Huh() {
  static $CI=null;
  if ($CI===null)
    $CI =& get_instance();
}
So in the libraries I would create a property of the class that was the CI instance, and in stand alone functions I would create a static variable that was the same.
The idea here was to only have to get the instance once and from then on it would always be available as needed.

But if you want to save memory this is not the best way to go.
I changed all of my code to just grab an instance any time I needed it
i.e.
Code:
$CI =& get_instance();
So this code if put in any methods or functions only as they are needed will grab an instance.
Doing this I saved at least 5k of memory.

Ok, Ok, 5k seems like nothing, and admittedly it is not much.
But then I looked at the CI core.
What I found was that there are 4 libraries that use $this->CI in their code, Calendar, Profile, Session and Validation.
2 of these libraries, Validation and Profile I was using on my site.
So I modified these and found that a whopping 100K of memory was saved.
There also seemed to be a minor speed improvement. It was in the nature of a couple of 1000ths of a second but it did seem to consistently improve performance by that small amount.

So the points I think to make here are:
1. Do not put the CI instance into a static variable as it will use extra memory
2. Do not add the CI instance as a property of an object as it will use extra memory

Basically if you are memory conscious then you should treat the CI instance the same as any other library, helper etc and only load it as you need it.

And to the CI developers, I would like to see the libraries changed so that $this->CI is not used as it will make the CI code that much leaner and faster.

#2
[eluser]sleddog[/eluser]
Does anyone within the CodeIgniter development team have a response for this thread?

Are the following 2 points correct?

1. Do not put the CI instance into a static variable as it will use extra memory
2. Do not add the CI instance as a property of an object as it will use extra memory

#3
[eluser]sleddog[/eluser]
Also I noticed that within the Output class (_display() function). The Benchmark and Config classes are retrieved using globals:

// Note: We use globals because we can't use $CI =& get_instance()
// since this function is sometimes called by the caching mechanism,
// which happens before the CI super object is available.
global $BM, $CFG;

Should the base $CI object be retrieved using globals as well, or is the get_instance() function faster?

#4
[eluser]sleddog[/eluser]
I have created a new thread:
http://ellislab.com/forums/viewthread/75649/

for the global vs get_instance() discussion.

#5
[eluser]sleddog[/eluser]
Update from thread: http://ellislab.com/forums/viewthread/75649/

use $CI =& get_instance(); as opposed to global $CI;

Still have an open question about the 2 points tonanbarbarian made:

1. Do not put the CI instance into a static variable as it will use extra memory
2. Do not add the CI instance as a property of an object as it will use extra memory


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.