This should be addressed by this commit submitted some days ago, AFAIK. https://github.com/wikimedia/jquery.uls/pull/97

(In reply to comment #1)

This should be addressed by this commit submitted some days ago, AFAIK.
https://github.com/wikimedia/jquery.uls/pull/97

Matmarex, Santhosh, can you please confirm this statement?

Sadly it probably won't help (that patch only addresses performance issues on showing the main ULS window).

Ok, sorry, I may misremember a comment about that screenshot and commit.

I'm sorry, but I have to closed this issue as invalid. Please use http://www.mediawiki.org/wiki/How_to_report_a_bug as a guide on providing actionable reports of issues you encounter.

Detailed steps to reproduce, operating system (with version) and browser (with version) are at least needed to look into this any further.

Please do reopen if the issue persists and once the needed information is added.

(In reply to comment #5)

Please do reopen if the issue persists and once the needed information is
added.

Reported at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=562795903#Unresponsive_script:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z:106

1. Windows Vista SP2
2. Intel Celeron 1.60 GHz, 1 GB RAM, 36 MB free RAM
3. Monobook and Firefox 6.0 ["If it ain't broke, I don't usually fix it. I have noticed that some of the newer versions of Firefox hog less memory, so I probably will upgrade it at some point"]
4. Reported happening 100 % times for [[Pittsburgh Steelers]], [[Barack Obama]], [[Alec Douglas-Home]].

Please provide details on which component is causing the delay.

(In reply to comment #7)

Please provide details on which component is causing the delay.

Please provide instructions to be given to the user on how to provide such details.

(In reply to comment #8)

(In reply to comment #7)

Please provide details on which component is causing the delay.

Please provide instructions to be given to the user on how to provide such
details.

First step would be to stop using a browser that is out of support and update to the latest release of Firefox. Then it would be useful to know if the problem is still present.

(In reply to comment #9)

(In reply to comment #8)

(In reply to comment #7)

Please provide details on which component is causing the delay.

Please provide instructions to be given to the user on how to provide such
details.

First step would be to stop using a browser that is out of support and update
to the latest release of Firefox. Then it would be useful to know if the
problem is still present.

These are not instructions to get the information you requested in comment 7, so I'm confused as regards what's needed.

Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. Note that this is a borrowed machine I don't usually have access for; I'll relay to the user instructions requested in comment 8.

(In reply to comment #11)

Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM. Note
that
this is a borrowed machine I don't usually have access for; I'll relay to the
user instructions requested in comment 8.

Thanks. Use firebug (http://getfirebug.com/javascript) and profile the page load and display.

(In reply to comment #12)

Thanks. Use firebug (http://getfirebug.com/javascript) and profile the page
load and display.

I can't do this myself, do you know of a link to a tutorial I can point the user to? Thanks.

The root cause of this is most like ULS using a *synchronous* AJAX API request on every page load (grep for "async: false").

I didn't expect to find something like that in real deployed code. It's seriously "The Daily WTF" material.

Moving back to ULS component. Siebrand, fix this and stop acting like it's not your problem.

(In reply to comment #14)

The root cause of this is most like ULS using a *synchronous* AJAX API
request on every page load (grep for "async: false").

Are you able of providing more information, Bartosz? I don't know how to look into this.

(In reply to comment #15)

Are you able of providing more information, Bartosz? I don't know how to look
into this.

Grep the mediawiki/extensions/UniversalLanguageSelector repository "async: false". The offending file is lib/jquery.i18n.js, in particular these lines:

		jsonMessageLoader: function ( url ) {
			var that = this;
			return $.ajax( {
				url: url,
				dataType: "json",
				async: false
			// that is unfortunate
			} ).fail( function ( jqxhr, settings, exception ) {
				that.log( "Error in loading messages from " + url + " Exception: " + exception );
			} );
		},

Make it load it asynchronously. Depending on how badly the rest of the code is written, this might require just changing 'false' to 'true' or rewriting half of the library. It's a nasty issue anyway that should have been avoided from the start instead of fixed now and I'm not going to dig into it for my own sanity. Sadly you guys are paid for this and this is your duty, so you have to. Good luck.

Actually, the right way to do this would be just not to send that API request and instead load whatever data you need via ResourceLoader.

Two more users reporting the issue: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=562994006#Heavy_Javascript_load_after_loading_some_articles.

The user did his best (1st try) of profiling and says: "jQuery.expr.filters.hidden() is the problem"

(In reply to comment #19)

The user did his best (1st try) of profiling and says:
"jQuery.expr.filters.hidden() is the problem"

i think this is a different issue. the report you quote pertains to a high-CPU-load issue, and this one is frozen-browser issue. (the other one is a real problem, but it's not the same as this one).

peace.

Change 71990 had a related patch set uploaded by Santhosh:
jquery.i18n message store for ULS

https://gerrit.wikimedia.org/r/71990

Change 71990 merged by jenkins-bot:
jquery.i18n message store for ULS

https://gerrit.wikimedia.org/r/71990

• Bug 50245 has been marked as a duplicate of this bug. ***

(In reply to comment #22)

Change 71990 merged by jenkins-bot:
jquery.i18n message store for ULS

https://gerrit.wikimedia.org/r/71990

maybe replying to a bot is plain stupid of me, but let me try:

the problem of freezing the browser is plainly and clearly related to calling ajax with "async:false".

it is also very clear why this type of problem will be intermittent: it depends on the network and the server: if the network and server are both A-OK, the user will hardly notice any problem.

however, if the localized messages page does not arrive to the browser promptly, "async:false" basically *tells* the browser to freeze.

since this patch does not remove the "async:false", it should not be expected to solve the issue.

(as of now, it's line 481 in jquery.i18n.js on head version in git: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUniversalLanguageSelector/HEAD/lib%2Fjquery.i18n.js )

peace.

kipod, that path of code in the library will never get executed from ULS. If you read the code again, you will see that instead of using jquery.i18n message loading mechanism, which is generic, not written specifically for MW, we have our own message loading and saving mechanism, that always use asynchronous loading. Look for the MWMessageStore definition in the code. Thanks.

(In reply to comment #25)

kipod, that path of code in the library will never get executed from ULS. If
you read the code again, you will see that instead of using jquery.i18n
message
loading mechanism, which is generic, not written specifically for MW, we have
our own message loading and saving mechanism, that always use asynchronous
loading. Look for the MWMessageStore definition in the code. Thanks.

not sure i understand. this code has your signature/copyright messsage, and appears in the tree under "univerals language selector".
what is the generic library this was imported from?
is it used for anything other than ULS?
if it's never executed, why is it there? what's the point of keeping dead code in the tree?

is it possible to remove all the dead code from the project?
i think this will help volunteers (and non-volunteers) to identify the *real* problems a bit easier.

in any event, if this code is never executed, then we can't blame "async:false" for the lockups, so "someone" has to figure out the real cause for the lockups many users reported.
if you think some other code change maybe solved the problem, it may be worthwhile going back to those people to find out if the problem still exists.

peace.

On my browser the line:

webfonts.$element.find( '*[lang], [style], [class]' ).each( function( i, element )

of jQuery.webfonts.js (about line 134). seems to be expensive.

Firefox 22, Windows 7 & Vector, 2 GB
Firefox 22, Linux kernel 3.5 branch & Monobook, 4 GB

http://bits.wikimedia.org/hr.wikipedia.org/load.php?debug=false&lang=hr&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130620T163512Z:106

Vector & Windows URL of unresponsive script

Firebug profiler reports 9210 calls & 20186.226ms in

http://bits.wikimedia.org/hr.wikipedia.org/load.php?debug=false&lang=hr&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z

Total is (22094.644ms, 152876 calls), so above is 91.36 %.

(In reply to comment #29)

Firebug profiler reports 9210 calls & 20186.226ms in

http://bits.wikimedia.org/hr.wikipedia.org/load.
php?debug=false&lang=hr&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.
triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.
MwEmbedSupport&only=scripts&skin=monobook&version=20130620T163512Z

Total is (22094.644ms, 152876 calls), so above is 91.36 %.

can you run the same profiling again, but with "?debug=1" added to address line?
this will allow to identify the actual file/function much better.

peace.

(In reply to comment #27)

On my browser the line:

webfonts.$element.find( '*[lang], [style], [class]' ).each( function( i,
element )

of jQuery.webfonts.js (about line 134). seems to be expensive.

this seems to be related to bug 50836 (i.e., performance vs. freeze).
i think if you'll dig a bit deeper you'll find that the expensive part there is calling "getCSS()".
this can be easily improved by doing the little optimization i outlined there for the "load" function.

peace.

this seems to be related to bug 50836 (i.e., performance vs. freeze).
i think if you'll dig a bit deeper you'll find that the expensive part there
is
calling "getCSS()".
this can be easily improved by doing the little optimization i outlined there
for the "load" function.

peace.

Depending on the browser, a high cpu spike could equal browser lock up until its done doing what its doing. Are we sure these two bugs aren't the same issue?

This time 9223 calls, 20145.512ms &debug=1 gives:

load.p...163512Z (line 6824)

if ( window.getComputedStyle ) { 6822
curCSS = function( elem, name ) { 6823
var ret, width, minWidth, maxWidth, 6824
computed = window.getComputedStyle( elem, null ), 6825
style = elem.style;

Seems like recursion on window.getComputedStyle().

That sounds like something is calling $el.css('property') repeatedly without caching the result. So it's either yet another performance issue (fourth or fifth by my count) or an error in the measurement method.

(In reply to comment #33)

That sounds like something is calling $el.css('property') repeatedly without
caching the result. So it's either yet another performance issue (fourth or
fifth by my count) or an error in the measurement method.

I think its the same issue that I was having

Created attachment 12808
Screenshot on Firefox 22.0 (Win XP)

Attached:

(In reply to comment #33)

That sounds like something is calling $el.css('property') repeatedly without
caching the result. So it's either yet another performance issue (fourth or
fifth by my count) or an error in the measurement method.

this actually *is* bug 50836.
there is a little explanation there (getCSS() is called from "load", but the results are not cached, as you and Bartos noted), and an untested patch that fixes the issue.

if the people who reported the "freeze" can confirm they see high cpu usage during the time the browser is frozen, i think it would mean that you were right, and the two reports are actually duplicates.
Either way, the profiling information definitely fits bug 50836 .

peace.

(In reply to comment #36)

if the people who reported the "freeze" can confirm they see high cpu usage
during the time the browser is frozen, i think it would mean that you were
right, and the two reports are actually duplicates.
Either way, the profiling information definitely fits bug 50836 .

I can confirm that. High CPU usage is present even without the "freeze". On a Quad Core@3GHz, Firefox does not freeze, but one of the cores is 100% busy. On a Dual Core@2.40GHz, Firefox freezes and again, one core is at 100%.

Just a note that the Language Engineering team responsible for ULS will be holding an office hour later today, at 17:00 UTC on
#wikimedia-office (on Freenode): http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69718.html

(In reply to comment #11)

Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM.

Work for me with that machine on http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama after https://gerrit.wikimedia.org/r/72967, no idea about CPU usage (though I watched it).

(In reply to comment #39)

(In reply to comment #11)

Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM.

Work for me with that machine on
http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama after
https://gerrit.wikimedia.org/r/72967, no idea about CPU usage (though I
watched
it).

Works as in doesn't freeze; I'm no longer served the font to see the dv interwiki, I don't know if this is expected (chr font is missing for me in both cases). On Linux/AMD E350 I definitely notice the CPU usage decrease too (bug 50836).

(In reply to comment #40)

(In reply to comment #39)

(In reply to comment #11)

Confirmed on Firefox 21.0, Windows XP SP3, Intel Atom N270, 1 GB RAM.

Work for me with that machine on
http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama after
https://gerrit.wikimedia.org/r/72967, no idea about CPU usage (though I
watched
it).

Works as in doesn't freeze; I'm no longer served the font to see the dv
interwiki, I don't know if this is expected (chr font is missing for me in
both
cases). On Linux/AMD E350 I definitely notice the CPU usage decrease too (bug
50836).

Nemo, thanks for this comment - it helped us uncover another bug, which we fixed before the deployment.

The fixes are deployed now, so the major performance problem should be mostly resolved now. Please test.

Runtime analysis done with Firefox 22's profiler

Hmmm... It's much better now - but it's still slow as hell.

See the runtime analysis I just did with Firefox 22's internal profiler on Windows 7 x64 loading [[en:Special:RecentChanges]] (using debug=yes).

Attached:

Created attachment 12818
Flame chart profile

Attached:

Created attachment 12819
Tree profile

In your screenshot I don't see anything that hints to ULS webfonts loading.

Here are my profiles on Chrome. You can clearly see that webfonts are in the call stack. They still do take time, but less than before the performance fix I deployed few hours ago. The time taken is split between curCSS and appendChild (adding the font-face definitions to CSS).

Attached:

i think this should be closed.
did not see any report about freezing browser since the patch was deployed.
did anyone see any more report(s) about browser freezing after the patch was deployed?

peace.