Client-side applications are becoming more important. There are plans for using AJAX, and request rates for machine interfaces such as query.php, action=raw and Special:Export are growing. These lightweight requests are often predominantly composed of startup costs. Profiling on Wikimedia currently gives 47ms for startup, including at least 8ms for extensions. This is too slow. My ideas for fixing this are as follows:
* Pervasive lazy initialisation. Remove $wgUser, $wgLang and $wgContLang, replace them with wfGetUser(), wfGetLang() and wfGetContLang(). This brings them into line with the successful wfGetDB() interface. Simply returning the variable would be done by those functions, if it doesn't exist, then execution would pass to the relevant autoloaded module for initialisation. The same can be done for $wgTitle, $wgParser, $wgOut, $wgMessageCache... pretty much all the object globals. A version-independent accessor would be put in ExtensionFunctions.php, to support multi-version extensions. By deferring everything, we allow lightweight requests to get by without ever initialising a user object, or loading a language file.
* Cached module registration. Each module provides a module.php in a unique directory, which sets a $module variable to an array describing its capabilities. Capabilities would include:
* Autoloadable classes and their locations * Hooks * Special pages * Magic words * Messages * Parser elements and functions
The registered callback functions would all be static functions in autoloaded classes. To register modules at startup, a function will be called with an array listing the extension directories. This function will load the module.php files and merge the arrays, creating a master hashtable of capabilities and their locations. And crucially, this hashtable can be cached. This reduces average-case module initialisation from tens of lines of code per module to a single unserialize() for all modules.
The old extension setup files would be kept for backwards compatibility, but would never be loaded unless the extension explicitly does so when it obtains control via a hook.
* Bring Wikimedia's configuration cache into the committed codebase, and extend its abilities. Incorporate settings from DefaultSettings.php into the SiteConfiguration object, thus allowing them to be cached, avoiding a DefaultSettings.php load. The bulk of the default LocalSettings.php can be moved to a separate file, analogous to Wikimedia's InitialiseSettings.php. Thus in the typical case, all configuration, except programmatic modifications, will be done by a single unserialize plus a few stat calls.
The general idea is to slash the number of lines of code loaded on startup to a tiny fraction of what it is now. Any thoughts?
-- Tim Starling