Last modified: 2010-05-15 15:33:38 UTC
Currently in REL1_4, ParserOptions::newFromUser() is called multiple times. AFAIK, there only needs to be at most one call for anonymous views, and two for logged-in views in general. Also $wgMsgParserOptions seems to be misnamed, but I'm ignoring that as a breaking change to extensions for 1.4. The patch (to be attached next) optimises this. It also makes greater use of PHP references for ParserOptions objects, with the exception of EditPage.php. According to the profiler here, the change speeds up rendering slightly, but YMMV. Nothing seems broken, but it's not worth doing more rigorous testing unless there's support for this change. Subject to feedback, something similar can be done for HEAD. I've done REL1_4 first as it was easier to work against a more stable codebase to see if this change worked. Also, in HEAD it may be worth reducing the amount of passing/copying of the ParserOptions object as a clean-up.
Created attachment 604 [details] REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences
How slightly is "slightly"?
Created attachment 605 [details] REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences (In reply to comment #2) > How slightly is "slightly"? Slightly, as in "is that all?". On a local test system with profiling enabled, the original saves ~10ms. The attached patch (with more Parser.php changes) saves a further ~50ms for each "If-Modified-Since"/"304 Not Modified" case. It also fixes a couple of problems in the last patch file.
The patches also accidentally fixed bug 1020.
Created attachment 607 [details] REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences (In reply to comment #4) > The patches also accidentally fixed bug 1020. Well they did one time, at Special:Preferences. Needs more work later. This update fixes a PHP 4 issue with the previous patches.
I'm unable to detect any performance difference. Loading a copy of [[Zuiderzee Works]] that I use for benchmarking. PHP 4.3.10 + Turck MMCache on Ubuntu Hoary, running on a 2GHz Athlon XP with 512 MB ram. MediaWiki REL1_4 current. Using Memcached cache backend. Benchmark method: Enabled logging+profiling, tailing the debug log via ssh from another computer. Loading page from web browsers in other computer. Doing four runs of each type in both logged-in and logged-out state, the three types being: * Client cache: plain reloading in Firefox, triggering a 304 response * Parser cache: reloading in Safari, triggering a 200 response pulling from the parser cache (Safari sends no- cache headers on reload, unlike Firefox) * Purge: an ?action=purge to force re-rendering Times given are milliseconds for 'total' time as reported by profiling, rounded to nearest millisecond. UNPATCHED, anon: Client cache: 16 17 17 17 Parser cache: 53 62 53 54 Purge: 251 249 288 285 UNPATCHED, logged in: Client cache: 16 16 16 16 Parser cache: 55 56 55 54 Purge: 287 253 287 286 PATCHED, anon: Client cache: 15 15 16 16 Parser cache: 54 54 53 52 Purges: 285 250 289 288 PATCHED, logged in: Client cache: 16 16 16 16 Parser cache: 55 53 57 56 Purge: 288 251 288 288
(In reply to comment #6) Dropping priority due to lack of improvement with Turck+Memcached. The slight improvement seen locally arose mostly from not having to call User::getSkin in the case of 304 responses. Test box was an old+slow server without $wgEnableParserCache, Turck, Zend, eAccelerator or Memcached.
Created attachment 608 [details] REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences Corrects reference-setting in Special:Preferences.
This bug is three years old. Either it is fixed already, or not important enough to warrant keeping a bug open.
