Last modified: 2009-09-04 03:02:32 UTC
Every call to API results in initialisation of LocalisationCache and loads of some stuff due to LocalisationCache::initLanguage() and User::getDefaultOptions(): SQL: SELECT /* LCStore_DB::get */ lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'deps' LIMIT 1 SQL: SELECT /* LCStore_DB::get */ lc_value FROM l10n_cache WHERE lc_lang = 'en' AND lc_key = 'preload' LIMIT 1 While it's not critical, performance could be improved by avoiding these calls.
There are various things in the API that use wfMsg[ForContent] and related functions, so the localization cache is needed.
(In reply to comment #1) > There are various things in the API that use wfMsg[ForContent] and related > functions, so the localization cache is needed. > Still, this loading could be deferred to when wfMsg() is actually called, not just for the API but for MW in general. Moving to i18n component and reassigning to Tim.
Works for me. Note that you have to disable any extensions that access the LocalisationCache during startup (there are many), and you have to use a suitable API module (not e.g. siteinfo) and a suitable formatter (not e.g. xmlfm). If you think there is a bug here somewhere, then you will need to show a backtrace, but in general I don't think there is a problem. Profiling has shown that preloading is a substantial win in almost all cases. If you have a very slow database, then you can use $wgCacheDirectory with DBA compiled in, to fetch the preload key from the filesystem instead. The whole LC project was an exercise in startup time optimisation, and simple API operations should be much faster in 1.16 than in 1.15.