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