The Moodle 2.0 css/js cache, minimization and fusion mechanism is cool.

But...

Maybe someone is asking, why after these optimizations moodle 2.0 appears to be more resource hungry (and slow) than older moodle?

When you call a php script with mod pre_fork you are instantiating about 32MB on RAM (php libraries needed to moodle), loading the interpreter, parsing etc.. for this loading a cached and minified css file in this way may be more resource comsming at server than getting 10 static css

So please consider to leave this cool idea due to this php limit (yes it is a php limit because it doesn't supports threads, so also with ningx, cherokee, lighthttp with fastcgi you need to allocate 32MB for each php process you want to "serve your server") and switch to a static file based mechanism like the joomla one (keeping your code to do minification etc... and simpling creating static snapshoots of your php output)

eg.

yui_combo.php?2.8.2/build/yahoo-dom-event/yahoo-dom-event.js&2.8.2/build/connection/connection-min.js

can be snapshooted (by itself) at first request time in

yui_combo.php_STATIC_2.8.2/build/yahoo-dom-event/yahoo-dom-event.js_2.8.2/build/connection/connection-min.js

and cleaned after 15 minutes (or configurable amount of time, like in joomla)

obviously the main php page (the page that prints style and js includes) should be able to detect when cache is expired and to request the .php file in that case, and after that, to request the "STATIC" one (that recreated the static version).

please, pelase consider to test this simple but amazing improvement: i can grant about a reduction of 80% in server load after that, test it with jmeter (with css fetching enabled).

This is a little code