Why does Model::_assign_libraries exist?

[eluser]Nate Wagar[/eluser]
Recently, my team had some issues with page performance on our server. After quite a bit of benchmarking and debugging, I discovered that the performance hit came straight from the stock CodeIgniter Model code, more specifically, _assign_libraries.

It's impossible to notice on most pages, however we have two pages that load 1500 models (rough estimate) for display. At this level, the overhead is quite visible, thanks to our scalability over speed SPARC processors.

When I discovered this, I started playing and made it do this instead:

Code:

var $db;
var $benchmark;
var $session;
var $load;
function _assign_libraries($use_reference = TRUE)
{
    $CI = & get_instance();
    $this->db =& $CI->db;
    $this->benchmark =& $CI->benchmark;
    $this->session =& $CI->session;
    $this->load =& $CI->load;
}

This took page execution from 14 seconds down to 6, and memory footprint from 18MB to 8MB. Obviously quite an improvement.

Knowing that this would cause problems down the line, I plan to tweak it even further:

Code:

function _assign_libraries($use_reference = TRUE)
{
        $this->CI = & get_instance();
}

and adjust all Models accordingly.

So my question is: Why aren't things done like this in the first place? (Or, will this break something that I don't expect?) Not being familiar with all the inner workings of CodeIgniter, I can't begin to answer these questions myself.

[eluser]Johan André[/eluser]
I don't know the solution to your problem, but one question that makes me curious is how you end up with 1500 models?

[eluser]Nate Wagar[/eluser]
We essentially set our project models up as an ORM. The result is an exponentially-increasing number of models (EventList contains Events, each of which contains a FeeList containing Fees, SeatTypeList containing SeatTypes, etc.)

Only a single page gets up to 1500, and that's a listing of all events in the database.

In hindsight, we may have gone a little overboard.

[eluser]danmontgomery[/eluser]
It assigns all members of the controller to the model for ease of access. If you aren't using those members, it shouldn't hurt anything... But if you start getting "undefined property" errors that would be the first place I'd look.

[eluser]Nate Wagar[/eluser]
I understand that, and am maintaining access to the CI libraries/functions by assigning the CI singleton by reference to a CI variable within Model. I'm simply wondering if there's some place in the CI core that will not expect this.

[eluser]wiredesignz[/eluser]
ORM is not a Model by definition and should not extend the CI Model class. If you do not require any CI features in your models why bother to extend the Model class at all?

[eluser]Nate Wagar[/eluser]
I have ORM on the brain, and should have said DAO instead. I only meant to imply that the models directly represent individual table rows.

I am in fact using CI features within the models.

[eluser]wiredesignz[/eluser]
Use PHP5 __get() rather than _assign_libraries() in your Base_Model class if you need one... but do not extend the CI Model class it is actually rubbish code.

[eluser]Nate Wagar[/eluser]
[quote author="wiredesignz" date="1283424310"]Use PHP5 __get() rather than _assign_libraries() in your Base_Model class if you need one... but do not extend the CI Model class it is actually rubbish code.[/quote]

Ah, and that was what I was getting at. But, it seems to me that most of the rubbish code in Model is concentrated in _assign_libraries, which is why I want to replace it with what I posted.