273797 - tomshardware.com High CPU usage in setTimeout()

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[q1]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041206 MultiZilla/1.6.4.0b
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041206 MultiZilla/1.6.4.0b

Visit the listed URL. Notice that Mozilla consume ~30% of the CPU continuously.
Nothing is changing on this page, so unless there's some script error, Mozilla
shouldn't use any CPU.

Reproducible: Always
Steps to Reproduce:
See above.
Actual Results:  
See above.

Expected Results:  
See above.

Comment 1

[Frankie]

definitely caused by this script which fires onLoad:

function checkLocation()
{
	object="thgnav";
	yy=eval(y);
	if (document.getElementById)
		document.getElementById("thgnav").style.top=yy
	else
		eval(dS+object+sD+v+yy)
		setTimeout("checkLocation()",10);
}

Sending to Javascript, but could be evangelism instead.

Comment 2

[Brendan Eich [:brendan]]

There's no point in throwing this out of browser-general without profiling data
to show where the cycles are going.

/be

Comment 3

[Frankie]

Brendan, where might we get a profiling-enabled build for OSX?

BTW, I confirmed that the excess CPU does not occur in W2K, only OSX.

Comment 4

[Brendan Eich [:brendan]]

bryner says "use Shark, it's part of XCode" for Mac OS X profiling.

/be

Comment 5

[Sterling Bates]

Just a heads-up that bug 276513 may have another testcase for setTimeout
performance (and may be a dupe of this bug, though it's filed against Firefox).

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm... not an issue on Linux either.  I'd love to see the Mac profiler data for
this.

Comment 7

[Richard Cunningham]

Attachment: Simplified testcase

I experience this bug on Linux on two completely different setups. I've created

this simplfied test case which i've tested on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050506 Firefox/1.0+
running on Mandriva 10.2 (2005LE)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Richard, if you're seeing something on Linux, chances are that it's a different
bug.  Please file it as a separate bug.  And please make the testcase say
something about expected and actual behavior; I can't see what's failing with it.

Comment 9

[Richard Cunningham]

ok, I realise now I am now only seeing it on my home system, which is quite old
(Celeron 450Mhz, 384Mb ram) so I'm not sure what I am seeing is a bug. The
setTimeout is set to 10ms so maybe it is just load issue due to running that
code 100 times a second.

Also I note that as far as tech-evangelism goes, all this code does is keep the
menu at the top of the screen, which jumps arround as you scroll down the page
anyway, it would be much better if the web-master of this site had used fixed
positioning for that div in browsers that support it.

Comment 10

[Frankie]

So, I finally load up Shark, start a trace, open the report URL...

...and the page has been redesigned (and redirected). Firefox displaying http://www.mobilityguru.com/2003/06/03/sneak_preview/ (same server, different name) takes 2-3% of a 1.25GHz G4. The culprit script no longer exists.

I tried several other pages on tomshardware.com and they all Work For Me too. Recommend marking this puppy Resolved.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Mmm....  Gotta love bugs with no testcase attached.  :(

Comment 12

[Wayne Mery (:wsmwk)]

simplified testcase attachment 182953 [details] works fine for Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070104 Minefield/3.0a2pre

bug 276513 however is still a problem, if not worse.

Comment 13

[Wayne Mery (:wsmwk)]

stefan, do you see this problem?  if so, where should this bug go?  And is bug 276513 a valid comparison?

reporter can't test, doesn't use MAC

Comment 14

[Wayne Mery (:wsmwk)]

Wayne, do you see this problem using attachment 182953 [details] on a MAC?

Comment 15

[Wayne Woods]

What should I expect to see? For me, Minefield 20070721 trunk nightly with just attachment 182953 [details] open seems to stabilize around 20% cpu usage. For comparison, Safari with the same attachment stabilizes around 9% cpu. I'm using a G4 system, OS X 10.4 and 1.25 GB RAM.

Comment 16

[Wayne Mery (:wsmwk)]

q1, has testcase impact changed for you?

wayne according to comment 0 "~30% of the CPU continuously" - which on your computer, assumed to be newer, might equate to your 20%.  

Comment 17

[Wayne Mery (:wsmwk)]

Wayne W in comment #15
> What should I expect to see? For me, Minefield 20070721 trunk nightly with just
> attachment 182953 [details] open seems to stabilize around 20% cpu usage. For comparison,
> Safari with the same attachment stabilizes around 9% cpu. I'm using a G4
> system, OS X 10.4 and 1.25 GB RAM.

bug 254884 talks about safari using less cpu

Comment 18

[Till Schneidereit [:till]]

tomshardware.com has been completely rewritten, as have substantial parts of Firefox since this was reported. I don't think there's anything actionable left here.