Last modified: 2009-09-04 03:02:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22340, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20340 - API loads unneeded things from LocalisationCache
API loads unneeded things from LocalisationCache
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.16.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-21 18:00 UTC by Max Semenik
Modified: 2009-09-04 03:02 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Max Semenik 2009-08-21 18:00:58 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.
Comment 1 Bryan Tong Minh 2009-08-25 19:56:05 UTC
There are various things in the API that use wfMsg[ForContent] and related functions, so the localization cache is needed. 
Comment 2 Roan Kattouw 2009-08-28 14:39:00 UTC
(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.
Comment 3 Tim Starling 2009-09-04 03:02:32 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links