Last modified: 2010-05-15 15:33:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2398 - Optimise constructions of ParserOptions::
Optimise constructions of ParserOptions::
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.4.x
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-13 06:57 UTC by Zigger
Modified: 2010-05-15 15:33 UTC (History)
1 user (show)

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


Attachments
REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences (9.09 KB, patch)
2005-06-13 07:00 UTC, Zigger
Details
REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences (12.89 KB, patch)
2005-06-13 12:00 UTC, Zigger
Details
REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences (12.88 KB, patch)
2005-06-13 14:35 UTC, Zigger
Details
REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences (12.89 KB, patch)
2005-06-14 01:50 UTC, Zigger
Details

Description Zigger 2005-06-13 06:57:23 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.
Comment 1 Zigger 2005-06-13 07:00:35 UTC
Created attachment 604 [details]
REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences
Comment 2 Brion Vibber 2005-06-13 07:04:21 UTC
How slightly is "slightly"?
Comment 3 Zigger 2005-06-13 12:00:38 UTC
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.
Comment 4 Zigger 2005-06-13 13:49:44 UTC
The patches also accidentally fixed bug 1020.
Comment 5 Zigger 2005-06-13 14:35:05 UTC
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.
Comment 6 Brion Vibber 2005-06-13 22:05:23 UTC
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
Comment 7 Zigger 2005-06-14 01:44:55 UTC
(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.
Comment 8 Zigger 2005-06-14 01:50:24 UTC
Created attachment 608 [details]
REL1_4 patches for Parser, Article, EditPage, MessageCache, OutputPage, Setup, SpecialPreferences

Corrects reference-setting in Special:Preferences.
Comment 9 Niklas Laxström 2008-07-13 18:50:59 UTC
This bug is three years old. Either it is fixed already, or not important enough to warrant keeping a bug open.

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


Navigation
Links