Views caching system

The Elgg's view system is said to significantly slow the Elgg down. Did anyone had a chance to investigate this in more detail though? What is the main factor that slows down the system? Did anyone run some more detailed tests? I think of implementing the cache system for views, though I didn't investigate the matter in detail. Any clues would be very helpfull.

  • Hi Vazco,

    So far as I know, the core team has carefully analyzed Elgg's performance using several tools including Cachegrind. The main analysis in the past has been that Elgg's performance is currently dominated by loading view files from the file system.

    The simplecache for CSS and JS and view path cache systems introduced in Elgg 1.5 has helped to some extent, but likely more could (and will) be done to cache views in the future,

    One problem with many view systems in general and Elgg's in particular is that views are not a function of a strict set of parameters but as they are PHP scripts, they can pull in data from anywhere.

    In my view, a side-effect-free templating system might help make view caching much easier (or even possible in many cases).

  • Right now I think of implementing the following invocation of views:

    elgg_view('viewpath', array('parameter1' => 1, 'parameter2' => 2), true);

    //where last parameter is caching.

    When cached, a view would create a single PHP file from all views that it contains -> eg. listing view from path 'pluginname/listing' that invokes many views, eg. 'output/text', would be fully contained in cache/pluginname_listing.php.


    Caching could be transitive (so that views from output/text would also be cached), though I think it's better to make them non-transitive for now.


    Of course, this would have to be a hack into the core or a patch, as it can't be implemented as a plugin.


    Maybe there is some more efficient way of addressing the problem though?

  • Hi Vazco,

    as I mentioned before, the main problem is that Elgg views are not a function of their parameters.

    You could pass the same parameters to a view at different times and get different results.

    View results depend upon the identity of the logged-in user, any value in the huge $CONFIG structure, and have access to arbitrary PHP functions (eg. time and date).

    This makes views difficult (maybe impossible) to cache.

    I think Elgg would need quite a different templating system before significant caching was possible.

    One of my favourites these days is StringTemplate:


  • It used to be the case that any values in $_SESSION over-rode view parameters, creating very strange and hard to track bugs.

    Just checked in Elgg 1.7.

    Yep, line 212 in


    $vars += $_SESSION;


    That sort of thing makes view caching essentially impossible unfortunately.