Tim Starling wrote:
The general idea is to slash the number of lines of code loaded on startup to a tiny fraction of what it is now.
Sounds like a good idea.
Tim Starling wrote:
Profiling on Wikimedia currently gives 47ms for startup, including at least 8ms for extensions. This is too slow.
Hmm... it would be a little nicer if we knew precisely what was causing that slowdown inside the startup. I know that MediaWiki has built in profiling calls, but have you tried a PHP-level profiler like APD yet?
Tim Starling wrote:
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.
It's probably a step in the right direction. But maybe it would be a better idea if we unified all these global object calls into a Registry object? (Perhaps this would be phasing them out that you described here: http://meta.wikimedia.org/w/index.php?title=Writing_a_new_special_page&d... )
Tim Starling wrote:
Cached module registration.
When you say "module" you mean, "extension", correct? So, essentially, we're finally going to structure the extensions into a much more orderly fashion. Sounds good.
Tim Starling wrote:
[on configuration]
I don't know enough about Wikimedia configuration to pass judgment here, but that sounds like a lot of code that hasn't been versioned.