Last modified: 2012-10-10 06:53:10 UTC
for last couple of weeks (at least) gu.wikisource has become very slow in typing. The issue is specifically on IE9 and IE6, but on firefox, speed is normal. on ws, typing input is very slow everywhere, e.g. search input, page text box, edit summary, etc. Tried disabling JS in IE9 and that brought back the speed to normal. <Dereckson> & <MatmaRex> tried some bits as well...
[ adding 'javascript' keyword ]
Does it happen only when Narayam is enabled or even otherwise? There is a IE fix waiting to be deployed for Narayam.
(In reply to comment #2) > Does it happen only when Narayam is enabled or even otherwise? There is a IE > fix waiting to be deployed for Narayam. It has been tested with Narayam disabled (using the own script checkbox enable/disable). It doesn't affect the issue.
Heard a similar comment from IE8 user as well.
Yes, I'm having this problem for a couple of weeks in IE 8. It's very very slow to type anything in tamil wikipedia. The problem exists in ta.wiktionary too. And when I open new sites in ta.wiki, get a message 'wheather to stop the script running in wikipedia pages, otherwise, the IE runs slowly'. Though I clicked on 'yes' to stop the script, it works slowly. I tried clearing the cache, but it didn't help either.
Bug 40890 might be related.
(In reply to comment #2) > There is a IE fix waiting to be deployed for Narayam. Srikanth: Any link to Gerrit handy?
(In reply to comment #6) > Bug 40890 might be related. I'd be pretty sure it is. (In reply to comment #7) > (In reply to comment #2) > > There is a IE fix waiting to be deployed for Narayam. > > Srikanth: Any link to Gerrit handy? https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/Narayam,n,z ^ I wouldn't say any of them are relevant...
Making highest priority for Santhosh.
(In reply to comment #9) > Making highest priority for Santhosh. http://blog.jquery.com/2012/09/20/jquery-1-8-2-released/ ^ Is that likely to help matters at all? https://gerrit.wikimedia.org/r/#/c/27298/
I doubt it, but there *is* something about "Performance degradation with delegate events and pseudo-classes" (#12436) in the changelog, which might just accidentally alleviated this issue as well. Needs to be tested.
*** Bug 40890 has been marked as a duplicate of this bug. ***
I'm using a mid 2010 MacBook Pro 2,66 GHz Intel Core i7 with Windows 7 with 2.4GB RAM and 2 cores assigned in VMWare 5.0.1. I've tested with Windows 7 (nlNL local), fully patched, with IE9.0.812. Site visited: http://sandbox.translatewiki.net This runs MediaWiki 1.21 alpha (master/HEAD) and the latest versions for extensions. Logged in user, with setlang=de Observations: 1. IME disabled in preferences: 4-5% CPU utilisation while editing* User:Siebrand 2. IME enabled in preferences, disabled in UI: 5-10% CPU utilisation while editing User:Siebrand 3. IME enabled in preferences, enabled in UI: 10-25% CPU utilisation while editing User:Siebrand * "editing" is in this case random keystrokes in the edit screen. Example: sdfsdfa sdfawerfavs bvsd vsdfvsdfvsdfvsdfvsdfv. I have no noticeable performance degradation, but I can imagine that for slower/older hardware it is noticeable. What I notice is that while inputting text in scenarios 2 and 3, my notebook fan starts buzzing. I'm going to pull in jQuery 1.8.2 from Gerrit change #27298 now, to see if that helps any. http://bugs.jquery.com/ticket/12436 was about "Performance degradation with delegate events and pseudo-classes". More later.
I could reproduce severe hanging on a Thinkpad T60 laptop (Intel Core2 2GHz, 2 GB RAM), IE 8, Windows XP SP3.
(In reply to comment #13) > performance degradation, but I can imagine that for slower/older hardware it is > noticeable. What I notice is that while inputting text in scenarios 2 and 3, my > notebook fan starts buzzing. > > I'm going to pull in jQuery 1.8.2 from Gerrit change #27298 now, to see if that helps > any. http://bugs.jquery.com/ticket/12436 was about "Performance degradation > with delegate events and pseudo-classes". > > More later. I use HP Pavilion g series laptop, with Intel core i5 processor, 2.4 Ghz, 6.00 GB RAM, 64-bit, installed OS: Windows 7 Home premium SP 1. I face serious performance issue in operating wikisource only in my IE9. Wikipedia and wiktionary works perfectly OK. In my office, all the Gujarati wikis are facing the issue of slowness, where I have IE6 installed and OS is windows XP. Don't know processor but RAM is 2 GB. So from my experience, it has definitely nothing to do with hardware as with 6 GB RAM and Intel i5 if it is slow, we must do something. This is not the first time that with mediawiki upgrade Gujarati wiki projects have suffered, couple of months back also we had issue after upgrade, see Bug 36275.
Update to comment 13: Using jQuery 1.8.2 doesn't appear to help much. I'd like to think that CPU usage has decreased by a few percent, but that's still not very significant. sandbox.translatewiki.net is now running jQuery 1.8.2 and I've just updated everything to HEAD of master again. Good luck digging into this, Santhosh.
(In reply to comment #16) > Update to comment 13: Using jQuery 1.8.2 doesn't appear to help much. Actually this appears to fix the issue for me. sandbox.translatewiki.net is smooth, I don't notice any slowness; about 5% processor usage (but this might be background processes and tabs). translatewiki.net is still unusable if Narayam is enabled; 100% usage and a few seconds of waiting every time I attempt typing.
(In reply to comment #17) > (In reply to comment #16) > > Update to comment 13: Using jQuery 1.8.2 doesn't appear to help much. > > Actually this appears to fix the issue for me. sandbox.translatewiki.net is > smooth, I don't notice any slowness; about 5% processor usage (but this might > be background processes and tabs). translatewiki.net is still unusable if > Narayam is enabled; 100% usage and a few seconds of waiting every time I > attempt typing. I'll update twn production, too. This is valuable info. Thanks for the feedback. I think Krinkle is in charge of deciding which version of jQuery we will be using. Krinkle: what are the current plans, and should we consider backporting 1.8.2 to 1.20, too?
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > Update to comment 13: Using jQuery 1.8.2 doesn't appear to help much. > > > > Actually this appears to fix the issue for me. sandbox.translatewiki.net is > > smooth, I don't notice any slowness; about 5% processor usage (but this might > > be background processes and tabs). translatewiki.net is still unusable if > > Narayam is enabled; 100% usage and a few seconds of waiting every time I > > attempt typing. > > I'll update twn production, too. This is valuable info. Thanks for the > feedback. > > I think Krinkle is in charge of deciding which version of jQuery we will be > using. Krinkle: what are the current plans, and should we consider backporting > 1.8.2 to 1.20, too? I'd be somewhat inclined to do so - it's a bugfix point release
FYI: translatewiki.net is now also on jQuery 1.8.2. Those effected, please test on https://translatewiki.net and let us know here what your test results are (see test plan in comment 13) and which hardware/software you are using if you still see issues.
(In reply to comment #20) > FYI: translatewiki.net is now also on jQuery 1.8.2. Those effected, please test > on https://translatewiki.net and let us know here what your test results are > (see test plan in comment 13) and which hardware/software you are using if you > still see issues. I tested translatewiki.net, and it works perfectly well. But not hadn't tested it earlier, so not sure whether the issue on gu:ws is related to it... can u plz. try reverting the same on there as well?
Sam/Reedy has just merged (Gerrit change #27369) and deployed[1] jQuery 1.8.2 on 1.21wmf1, which includes Wikimedia Commons and gu.wikisource. There may be some delay because of caching, but you can add "debug=true" as a CGI parameter to make sure you get the "current" JavaScript. I'm closing this issue for now, because I think it's resolved. Santhosh will double check in a few hours if there's anything that should be optimized in Narayam. [1] http://hexm.de/m4
Superb...! GU:WS fixed now. Thank you all guys! will check on my office IE6/IE7, hope there won't be any issue there either... any changes made on GU:WP as well? as on older versions of IE its sluggish across the gu projects, I assume with all Narayam installed wikis
(In reply to comment #23) > Superb...! GU:WS fixed now. Thank you all guys! will check on my office > IE6/IE7, hope there won't be any issue there either... any changes made on > GU:WP as well? as on older versions of IE its sluggish across the gu projects, > I assume with all Narayam installed wikis Oh, they will be slow... I've only backported it to 1.21wmf1 wikis (so all non wikipedia projects, plus enwiki). They are due for upgrade in around 18 hours. I'm not overly sure if it's worth backporting to 1.20wmf12 too. I can though if needed/wanted/requested
Done anyway https://gerrit.wikimedia.org/r/27379
Some more info from Gerrit change #27388: Remove the expensive event listeners In every keydown, keypress, focus, blur on the document, Narayam was triggering the jquery selectors - this is very expensive. This was done to enable Narayam on future DOM elements. This is very rarey used feature and its cost is high. As of now, I am not aware of any usecase which use this. If we notice such usecase we can add them in some UI context with narrow selector scope. Browsers like IE is very slow in executing jquery.on on selectors. See Bug 40630. Eventhough it was solved by jquery upgrade, it is not good to keep this feature in Narayam. Change-Id: I7c382913179af913aafd7ecca4dbc18a988ec1f9
