Load core, modules and tags on demand

[mnhg]

Hi,

I'm thinking about migrating the content of my own cms to CMSMS. Therefor I installed the current version and some modules and recognize afterward that a plain page need more than 8MB of memory. Even without modules it are 4MB. Can anybody tell me why the whole cms (with modules and tags ...) is loaded to generate a page and not only the necessary parts? Are there any plans to addressing this issue?

Are there larger projects realized with CMSMS?

mnhg

[Russ]

True it is a bit of a memory hog at present, but lazy loading of modules etc is coming and the memory footprint will get smaller.
On the other hand it is very fast and flexible and the memory used should not pose a problem even on many shared hosts?

Do you have a more specific problem?

I believe there are some quite large site using CMSMS and there are a variety of optimisation techniques discussed in these forums and in the documentation.

[NaN]

Uninstalling modules that are not used will decrease memory usage.
Ted Kulp already wrote that this behaviour "Load everything and use only what we need" will be changed in CMSms 2.0.
But it will be a long way until the first release.

The problem is, that CMSms does not know what modules are actually used in a template.
It would need to parse the entire template and all content to get all needed modules and only load them if they are installed and active. After this it would need to parse even all module templates and all module content of the found modules. Since the CMS does not know what module templates are used or what module action is processed because at this moment the module itself is not yet processed.
And after this it will start again if in the module template or content are modules used that are not loaded yet...
This will result in much recursion what would decrease the memory usage but increase the CPU usage.

It is not that simple to get a well balance between RAM usage and CPU usage to gain the most effective performance. 

[mnhg]

I don't get your point. In PHP4 you could simply use a proxy(not the network thing, the design pattern). You just have to find a nicer generic adaptation than in the following sample.

Code: Select all

function parse(&$text)
{
  include_once ("bb.parse.php"); 
  return bbparse($text);
}

In PHP 5 it's even simpler. You can use __autoload.

[calguy1000]

CMSMS 2.0 will require php 5.2+ and will use the autoload stuff extensively.
but as far as modules go it's a bit mroe complex than that.

a) we're dealing with legacy stuff here, and legacy support for php4, and also the way that modules behaved in the past.
b) there are different types of modules with different needs.  Some need (or needed) to be instantiated for each request.
- Some modules used the callbacks to trap when certain things happened in CMSMS (CustomContent was one of these) so that it could perform various actions.
- Some modules register smarty plugins of their own, and therefore need to be instantiated for each request (CGSimpleSmarty,      CGExtensions, FrontEndUsers)...
- Some modules, like News and CompanyDirectory could be lazy loaded, but the infrastructure didn't support that
- Some modules register event handlers, so they need to be instantiated in order to receive events.
   
To minimize memory utilization in the past we've moved alot of the functionality from the XXXXXX.module.php file into seperate actions (not all modules have caught up to this completely, that's up to each module developer and his/her personal priorities).... and have utilized classes and other function libraries, so that memory utilization is lower when the module is not used.

So, to sum it up....
a) we're aware of the difficulties, and the trade-offs... 
b) we're moving to lazy loading for alot of the core stuff, and I'm starting to use autoload in all of my modules now.
c) modules can't necessarily be lazy loaded.  Including some of the larger ones.
d) no matter what we do, we aren't gonna get away with having all of the functionality in the world run in 8mb of php ram.   
    so we're gonna put some reasonable effort into getting this better, and try to minimize memory requirements as much as is
    reasonably possible, but we're not gonna spend weeks re-designing stuff for a potential 10% reduction in memory usage
    (we'll get the big ones, but when effort exceeds reward we'll probably stop).