Last modified: 2014-11-07 14:05:21 UTC
Created attachment 12873 [details] Runtime profile created with Firefox 22's internal profiler, "debug=true", soft reload (e.g. caches should be available) I'm facing a severe performance issue on history pages in Firefox 22 on Windows 7 x64. Page load is very slow (with bits.wikimedia.org being acesses multiple times in the beginning), later on there seems to be executed some heavy JavaScript which makes the browser unresponsive over large amounts of time. I'll attach an image which shows Firefox's native profiler window. It seems there are mainly three functions taking up most of the CPU time: 1) "curCSS()" which is called from an anonymous function in "mediawiki.searchSuggest.js" 2) "updateDiffRadios()" which gets called from "jQuery.prototype.ready()" in "load.php" 3) "DocumentUtils_getFormData() which gets called from "ssi_onTimerCallback()" in "SessionStore.jsm" While 2) looks to be clearly related to history pages, 1) puzzles me. I have no idea about 3).
Forgot to mention, I visited http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&action=history&debug=yes
The problem only happens when I'm logged in, not when logged out. I emptied out my common.js for debugging purposes but it didn't change anything. I'm also not aware of any gadget on enwiki that could cause this problem.
How many seconds does "severe" mean? Being logged in and using Firefox 22.0 on Fedora 19 with Firebug, it takes 13 to 18sec for the link in comment 1 when using Ctrl+F5. It lists 168 requests. I'm in Europe. > Runtime profile created with Firefox 22's internal profiler Is there a how-to somewhere available?
Severe means - 16 seconds for a normal page load (with caches available) - 20 seconds when holding shift on reload (e.g. reloading the page completely discarding caches) > Is there a how-to somewhere available? Just use "Tools -> Web Developer -> Profiler" (Shift-F5) Then click start, reload the page, click stop when reloading is done. Firefox then automatically analyzes the recorded data and shows a runtime profile.
(In reply to comment #0) > I'm facing a severe performance issue on history pages in Firefox 22 > on Windows 7 x64. Page load is very slow (with bits.wikimedia.org > being acesses multiple times in the beginning), later on there seems > to be executed some heavy JavaScript which makes the browser > unresponsive over large amounts of time. Debug mode *is* slow. If this is not an issue in "regular" mode, then I wouldn't bother, really. > 1) "curCSS()" which is called from an anonymous function in > "mediawiki.searchSuggest.js" This is a red herring; curCSS() is internal jQuery function which is called by basically everything everywhere. (Primary offender here might be the ULS extension, see bug 49935.) > 2) "updateDiffRadios()" which gets called from > "jQuery.prototype.ready()" in "load.php" Yeees, this might be an issue, but I have never experienced substantial slowdown related to this myself, and I'm on a mid-end laptop. > 3) "DocumentUtils_getFormData() which gets called from > "ssi_onTimerCallback()" in "SessionStore.jsm" Sounds like a Firefox extension.
(In reply to comment #5) > Debug mode *is* slow. In fact it is, but it still takes at least 8 seconds to load the page without "debug=yes". Open three history pages from watch list and the Browser is locked up for half a minute. Especially since the JavaScript locks the browser regularly you cant just let the pages load in background but have to wait for them to finish loading. Not really acceptable after all. > This is a red herring; curCSS() is internal jQuery function which is called > by basically everything everywhere. (Primary offender here might be the ULS > extension, see bug 49935.) But what for is ULS needed on history pages? There are not even Inter-Wikilinks and also nothing else that would need any feature of ULS. It also isn't a big issue on other pages. > > 2) "updateDiffRadios()" > Yeees, this might be an issue, but I have never experienced substantial > slowdown related to this myself, and I'm on a mid-end laptop. Well, see above: It's an issue for me so there seems to be something different on our systems or you are less sensible to it. > > 3) "DocumentUtils_getFormData() > Sounds like a Firefox extension. In fact it seems to be one. Didn't know plug-ins were catched by the profiler. I'll upload another profile with Firefox started in safe mode.
Created attachment 12882 [details] Runtime profile with Firefox started in safe-mode (add-ons disabled)
This needs reproduction.
It helps to increase the number of entries shown on history pages to debug this. When set to the maximum (1000 entries) the lag should be noticeable even on high-end machines.
A month went by, the ULS bugs were (I believe) fixed. Can you try it again? (Without the extension as well.)
(And do not use debug=true; as I said in comment 5, page are much slower to load in debug mode by design; speed issues regarding it are thus WONTFIX.)
Sorry Andre, but its also slow without "debug=true". Therefore the title change is inappropriate. And I don't think this should be a low priority. The whole MediaWiki software is getting slower and slower with new features added. At some point optimization of existing features has to become a major priority!
@Bartosz Dziewoński: Yes, it's still slow. As said before: Set the number of entries on history pages to 1000 and try it on your own. Even without "debug=true" it's too slow to be usable. I assume most people don't set that value so high, but it definitely reveals a performance issue that should be looked into.
Changing the title then. I agree that if its only in debug mode then super low priority, but if its always slow, then its a real issue. (Particularly if it happens for other people too. If its just you, could be a problem on your end)
https://gerrit.wikimedia.org/r/133709
Change 133709 merged by jenkins-bot: History: Simplify checkboxes script on History pages https://gerrit.wikimedia.org/r/133709
OK, I think performance has significantly improved with this change. On a side note, Hovercards is performing terribly atm... Taking up 45% of the time on a complex page load.
Resolved? Not resolved?
Well, page loads are still pretty slow, especially when setting the number of revisions per page to something like 1000. So the patch might have improved the issue, but I wouldn't really describe it as resolved. I don't have enough knowledge of the code though, to assess whether further performance increases are realistically achievable. However, *if* they are it should definitely be done.
> OK, I think performance has significantly improved with this change. I'm very tempted to close this as WORKSFORME (though missing a new runtime profile to compare). There's no real criteria provided here when performance would be "fast enough", hence this ticket currently feels unfixable by definition.
(In reply to Andre Klapper from comment #20) > > OK, I think performance has significantly improved with this change. > > I'm very tempted to close this as WORKSFORME (though missing a new runtime > profile to compare). There's no real criteria provided here when performance > would be "fast enough", hence this ticket currently feels unfixable by > definition. Closing. If this still happens, some loading info available via the "Network" tab of your browser's developer tools is welcome!
