https://bugzilla.wikimedia.org/show_bug.cgi?id=57026
--- Comment #27 from Bawolff (Brian Wolff) <bawolff...@gmail.com> --- (In reply to comment #25) > > Also, there might still be a second parse from WikiPage::doEditUpdates() if > the > page uses magic words that access information about the current revision or > if > the page transcludes itself. I don't see any way around that. > > And I'm not entirely sure that just timing a null edit isn't going to cause a > parser cache miss for the view-after-save, particularly if your preferences > don't match the defaults. Do you still see double timing if you do the null > edit via the API? I was looking at firebug, and recording the time it took to retrieve the POST request that results in a redirect. After the redirect, firefox does a GET request which usually parses the page again, which I didn't count. I was testing https://commons.wikimedia.org/wiki/Commons:Featured_picture_candidates/Log/November_2013 and https://commons.wikimedia.org/wiki/Commons:Featured_picture_candidates/Log/October_2013 which a user at commons had previously identified as being slow. I don't believe these pages are vary-revision, but hard to be 100% sure of that I was testing via index.php. When I test via api.php, page save actions take the same time as rendering a page preview, which is interesting. Thus the issue I'm seeing seems to be from the web interface only. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
