Last modified: 2012-05-03 10:30:59 UTC
> * [[meta:Help:Enhanced recent changes]] > * [[meta:Help:Watchlist#Expanded_Watchlist]] Enhanced watchlist freezes the browser for 30 seconds after loading a big list (the time is relative to the number of entries displayed). $.fx.off = true; [[:bugzilla:30401]] doesn't help. Need to wait ~20-30 seconds after load for my watchlist to collapse all entries (yes, old computer - which should be enough!). Freeze after loading my (big) watchlist. 800 edits from the last 2 days (in Commons) to take 30 seconds to collapse (after the page is loaded)... This was way faster before the 1.18 update. Beau 2011-10-05 19:36:45 UTC https://bugzilla.wikimedia.org/show_bug.cgi?id=30401#c2 "Some people with older PCs from pl.wiki report long times to expand or collapse changes on enhanced recent changes or watchlist too."
There is also [[bugzilla:31832]] - but it doesn't mention watchlist or RC
A few questions for clarification: * Is this happening on every show/hide of a specific group? Or only at page startup time (when all the groups get pre-collapsed)? * Is that a big total list -- Like 100 or 1000 or 10000 separate edits being shown on the entire watchlist display? Or big in terms of a collapsed set of 10, 100, or 1000 edits on the same article that get shown/hidden together as a single group? * What browser and version? * What operating system and version?
It looks to me like jquery.makeCollapsible.js when running at initialization time for things meant to be pre-collapsed is... a little funky. It first does a toggleElement to collapse it with the 'instant' mode on, then it calls the click() handler, which via toggleLinkDefault ends up doing another toggleElement call, this time without the 'instant' mode on -- and that appears to start up a fade-out animation for each (already hidden) row. This could perhaps be slowing things down. :)
Added some notes on r82471 in CR...
(Note that per the above analysis, the thing that'll cause the biggest slowdown is having _lots of initially-collapsed groups_ on the watchlist. So a lot of pages that have been edited multiple times; each collapsed group will add to the slowdown.)
(In reply to comment #2) > A few questions for clarification: > > * Is this happening on every show/hide of a specific group? Or only at page > startup time (when all the groups get pre-collapsed)? Every show/hide is slower than before 1.18, too - but it just takes less than a second. Still annonying - but this isn't what the bug is about. The bug is about page startup when all entries are loaded and the JS kicks in and collapses the groups. > * Is that a big total list -- Like 100 or 1000 or 10000 separate edits being > shown on the entire watchlist display? Or big in terms of a collapsed set of > 10, 100, or 1000 edits on the same article that get shown/hidden together as a > single group? I noticed that: the time taken is relative to the days (URL parameter) displayed; which is roughly relative to the number of displayed edits. I had a look in the Firebug Network view: https://commons.wikimedia.org/w/index.php?action=raw&ctype=text/css&title=MediaWiki%3ACollapsibleTemplates.css is the last action. It takes this time on my current Commons watchlist: days |time (s) |edits | = edits/s 0.5 3 47 15,6 1 11 270 24,5 2 25 531 21,2 3 41 839 24,5 Cannot test if the time is related to the number of edits or the number of groups. > * What browser and version? As set in the bug details: Firefox 3.6 > * What operating system and version? openSUSE 11.1
(In reply to comment #5) > (Note that per the above analysis, the thing that'll cause the biggest slowdown > is having _lots of initially-collapsed groups_ on the watchlist. So a lot of > pages that have been edited multiple times; each collapsed group will add to > the slowdown.) Yes, the majority of pages displayed in my watchlist have several edits → collapsed group. I have counted for days=1 → 265 edits in 51 groups.
(In reply to comment #6) (where is the _edit_ button? .. crappy BZ) Machine: Pentium M 1,6 GHz (single core)
Tested with Opera 11.5 on the same machine: Interesting: Opera collapses the groups one by one starting on top with screen updates between each collapse. days |time (s) |edits | = edits/s 0.5 N/A 1 7 261 37 2 N/A 3 20 836 42
(In reply to comment #8) > Machine: Pentium M 1,6 GHz (single core) I think I may have one sitting around. Time to set up a testing enviornment on it!
a note to emphasize (I had already mentioned it above): it was faster before 1.18 - so somehow it worked there .. much faster. unless my brain really tricks me
I strongly suspect that this is the problem with FF3's javascript engine. I installed an older version of Suse (11.0) to get FF3beta5 and the recent changes page was *very* slow. More than once I got the dialog about slow javascript on the page. This was on a 2.2Ghz Celeron Linux box. I went to mozilla.org on that machine and downloaded the latest (FF8) and tried again. The page did pause, but there were no dialogs or anything telling me the JS was too slow. After a few of seconds (much less than 30, more like 2), the page was usable.
one more test: I just have tested on a 1.7 GHz Athlon XP, WXP. * The RC with limit to 1000 entries takes about ... to collapse (frozen in the meantime). ** FF8: 6-7 seconds ** IE8: 100 entries: 7s. 250 entries: 40s. 500 entries: 150 s https://commons.wikimedia.org/w/index.php?title=Special:RecentChanges&limit=500 Impressive result on IE8: the PC is usually faster than my notebook but IE8 totally fucks up. I killed it three times when I was calling the 1000 entries list because I thought it was crashed. ;-) On my 1.6 GHz notebook with FF3.6 the current RC with limit 500: 16s limit 1000: 42s. Note: limit=1000 covered about 45 minutes of edits. The result on FF8: It still is consuming way to much CPU consumption for this simple operation. I will try to put FF8 on my 1.6 GHz Notebook with FF 3.6 and see.
View this here: https://commons.wikimedia.org/?curid=17431178 * Notebook, Pent.M 1.6 GHz - WXP (not openSUSE as usually) ** '''FF3.6''', no Addons/Plugins, new Useraccount, enh. RC: *** RC500: 10 s *** RC1000: 44 s ** FF3.6, Noscript, same new Useraccount, enh. RC: *** RC1000: 40 s ** FF3.6, Noscript+Adblock with my blocklist, same new Useraccount, enh. RC: *** RC1000: 40 s ** FF3.6, Noscript+Adblock with my blocklist, same new Useraccount, enh. RC, Monobook skin: *** RC1000: 55 s 50s 50s ** FF3.6, Noscript+Adblock with my blocklist, user:Saibo, enh. RC: *** RC1000: 85 s (2x tested) ** FF3.6, Noscript+Adblock with my blocklist, user:Saibo but with emptied monobook.js, enh. RC: *** RC1000: 65s ** '''FF8.0''', Noscript+Adblock with my blocklist, same new Useraccount, enh. RC, Monobook skin: *** RC1000: 4s ** '''IE8'''.0.6001, no Addons/Plugins, same new Useraccount, enh. RC: *** RC500: 10 s *** RC1000: 40 s ** IE8.0.6001, no Addons/Plugins, same new Useraccount, enh. RC, switched to compatibility mode: *** RC500: 50 s *** RC1000: 300 s ------- Conclusion: Either IE8 in compat. mode and FF3.6 have a fuckin' slow JS engine/DOM manipulation or the code (it is jQuery, isn't it) uses different methods for different browsers. FF8 is okay although not fast IE8 without compat. mode is not really nice and IE8 with compat is unusable. Note that AFAIK IE8 sometimes switches on the compat. mode without user interaction - so this could happen for some users.
Yup. Problem is the many reflows the makeCollapsible JS causes. See the duplicate bug, which contains a patch that brings some relief (though it still doesn't make FF3.6 hyper-fast). *** This bug has been marked as a duplicate of bug 34876 ***
