64516 - 95-99% CPU usage for dhtml "snow effect"

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P2)

Description

[Eugene Savitsky]

Load the page, look at CPU usage. It's about 99%!!!!!

I'm sure it's about the snow...

2001010404 win2000, duron 900, 320Mb, 60Gb RAID (2*30Gb IBM DTLA).

Comment 1

[Eugene Savitsky]

Some more info about CPU usage:

NN4.76 -     38-45%
IE5.5 -      66-85%
Opera 5.01 - 95-99%

Comment 2

[Matthias Versen [:Matti]]

I see this too.
win2k build 2001010420.
87% cpu usage with an Athlon 900 / 256 MB

Comment 3

[Boris Zbarsky [:bzbarsky]]

I see this on Linux as well.

Comment 4

[Håkan Waara]

Yup, the snow is almost "lagging" on my system.

Comment 5

[Asa Dotzler [:asa]]

anyone have any ideas what's pegging cpu here. is this a js engine performance
issue?

Comment 6

[timeless]

It runs in the main thread and doesn't nice itself. => jseng c/o brendan

Comment 7

[Brendan Eich [:brendan]]

This is so not my bug, and don't be doing facile reassigns based on some theory
that JS in the same thread as Gecko is bad, timeless (it's the only way to do JS
and the DOM, given Gecko's single-threadedness).

The script uses setTimeout(..., 10), which leaves plenty of time between JS
runs.  Unless you can profile and show that most of the cycles are in the JS
engine, this bug should go to someone else, probably lucky jst.  Cc'ing shaver
as I recall he looked into DHTML perf probs last year.

/be

Comment 8

[Phil Schwartau]

Setting default component -

Comment 9

[Johnny Stenback (:jst)]

I guess part of the slowness is due to our non-optimal getElementsById(), I'm
trying to figure out where we spend all the time here...

Comment 10

[Johnny Stenback (:jst)]

Attachment: Quatify data

Comment 11

[Johnny Stenback (:jst)]

I just attached a file with some quantify data that I just collected and it
appears that when scoping at GlobalWindowImpl::RunTimeout() (which is what
executes the JS timeout) and from looking at the data I concluded that
getElementById() takes up a ~5% of the time, which admittedly is alot, but it's
not the big problem here. Most of the time seems to be spent doing reflow when
the snowflakes are moved so I'm reassigning this to buster for futher
investigation. It seems like every executing every timeout takes about 38ms on
my computer and the timeout is 10ms so we'll be awefully busy to keep up with
that, thus the 100% cpu useage.

Comment 12

[Johnny Stenback (:jst)]

Those numbers were collected using a debug build btw, so there could be some
debugging noice in there...

Comment 13

[buster]

call me stupid, but I don't see any reflow in the quantify data you posted.  It
looks like style resolution to me.  Am I missing something?

Also, what platform were you on when you collected the data?

Comment 14

[Marc Attinasi]

I am not realy surprised by this. Viewer test13 has the same problem, as do many
other sites with very short timer durations.

I am very curious why Reflow is NOT in the data - clearly if the snowflakes are
moving around _something_ has to be getting reflowed... or am I the stupid one?

Comment 15

[Johnny Stenback (:jst)]

I'm the stoopid one here, I'm the one blaming reflow w/o really looking at the
data, I just saw it went past the DOM code w/o spending too much time there and
made incorrect assumptions...

Reflow is in the full data set (I only posted part of it), let me know if you
want more data, I still have the whole quantify dump (72MB) on my hard disk, or
I could post more from the same list I grabbed the first part from.

Sorry about blaming the wrong piece of code here.

Comment 16

[Johnny Stenback (:jst)]

The data was collected on WinNT 4.0, btw, 400MHz

Comment 17

[buster]

JST:  please post the additional data that includes reflow (just a top level
cost for reflow would be sufficient, like maybe the F+D time for CanvasFrame
reflow.  It's interesting only to understand the relative cost of style
resolution and reflow.  We're assuming that style resolution dominates, but if
that's not true we'll go down a different path.

Comment 18

[Johnny Stenback (:jst)]

Here's the data for CanvasFrame::Reflow():

0.88
109933.85
27
CanvasFrame::Reflow

I'll attach all the data for the GlobalWindowImpl::RunTimeout() scope (i.e. the
comlete list of which I only attached a part earlier).

Comment 19

[Johnny Stenback (:jst)]

Attachment: More of the above quantify data

Comment 20

[Johnny Stenback (:jst)]

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

Comment 21

[Marc Attinasi]

Script is modifying the style attribute via the DOM, which is causing a lot of
extra work since we have to reresolve style on the element, not knowing what
actually changed in the style attribute.

Buster had an idea that maybe we can be smarter about handling changes to the
style attribute, like looking at what has changed and restricting the impact
when possible. For example, if it is just the position of an element chaning we
cna optimize to move the element, and avoid the need to reresolve style and do
the style-change reflow...

Comment 22

[rbs]

Another snippet from buster taken from Marc's posting in "The Jackpot"...

> If necessary, we could do this by having the style system examine 
> the change, determine which attributes were added/deleted/changed, and 
> call back to the content to get the hint for each (for example...I 
> hope it can be simpler than that, even.)

Sounds like a neat idea to me. And it is extensible to all kinds of attributes.
Indeed, with an appropriate data structure, the whole lot can be passed to the
_frame_ in one go. This way, the frame will also be given a chance to reply to
the Style System that it doesn't want style re-resolution, and that it can deal
with the change by just repainting/reflowing itself (in the subsequent 
AttributeChanged() notification that it will receive). This way of doing so will
even encompass hyatt and shaver solutions, because the granularity of what to do
will be determined by the frame itself (and a frame is in an enviable position
to determine the lowest/highest thing that can happen with a particular change).
Besides, the frame can call another generic method (a default no-op? or a
case-by-case a la shaver) in the content to also get what the content thinks.

Had frames been involved in the determination of the hint, hyatt solution would
amount to just return an appropriate hint that avoids style re-resolution.
Hope my understanding of the issues is correct.

Comment 23

[Marc Attinasi]

Hyatt's new patch attached to bug 68103 does basically that: his content element
just returns a new hint that the style system understands to mean 'just notify
the primary frame and don't reresolve any new style'. I'm still trying to grok
how the frame could get involved though...

Comment 24

[Mike Shaver (:shaver emeritus)]

rbs, I don't understand how the frame/element can know whether there are any
other style rules with selectors containing the attribute in question.  Surely
it has to ask the style system about that?

Or do we just make it illegal to write selectors that involve those attributes? 
I think that would suck.

Comment 25

[rbs]

OK, let's suppose that the frame was given a chance to reply to the request for
the GetMappedAttributeImpact(). In the case of XUL (hyatt case), the frame would
reply as hyatt did (no-op). In other particular cases, e.g., position, the frame
could well reply the same no-op, and later do the movement/repaint when it gets
the AttributeChanged().

In complex cases, the frame can bail out to its content :-) So, at worse this
scheme cannot do as much work (re-resolve) than what is presently done, and if
used in conjunction with AttributeAffectsStyle() in the Style System, there will
still be win. Also, there are some attributes that are irrelevant to a frame
(and its subtree), and it is conceivable that the frame can reply that it
doesn't care so that the Style System will avoid to re-resolve (this may have
the side-benefit of catching the mis-use of some attributes in XUL--because the
expected effect wouldn't be updated and people will wonder why and will have
to fix their mis-use).

The fact that frames become involved just enable a finer granularity on the
choice of the hint, while letting the Style System still responsible to fire
the AttributeChanged() [this is vidur's point], with possibly another hint if
deemed necessary.

Comment 26

[rbs]

Just thought that it is very important to keep the Style System part of the
game because someone can later try to getComputedStyle... In particular, for
properties that can be inherited, it is really up to the Style System to take 
the final decision on whether to (or not to) re-resolve even though what is
requested may not have any visual impact at the time of the change.

Comment 27

[rbs]

Another radical alternative could be to see if re-resolve can be made lazy, eh?
Say a style context has a mState with various bits (DIRTY_xxx) that are set in
the context (and in the corresponding style subtree for inherited properties)
when a property is *changed*. Then only trigger the actual re-resolve if someone
tries to GetStyle() on a child style context for which a property is dirty. This
re-resolve would then crawl the subtree all the way up to the clean ancestor, 
and trigger the re-resolve from there (while still leaving other unaccessed 
subtrees dirty, so long as they have a different ancestor). Hence, all the stuff
that were dirty in the subtree would become clean in one batch. (How generally
deep is a subtree, often around 10?)

So things could remain as they are presently, and frames could query the style 
context [mStyleContext->GetState()?] and try to optimize their work without 
triggering the re-resolve (e.g., in the case of the DIRTY_POSITION as suggested 
in this bug). How feasible/efficient is this, I can say much :-)

Comment 28

[rbs]

s/I can say much :-)/I can't say much :-)/ !!!

Comment 29

[buster]

rbs's last idea is creative, but I think it's going down the wrong track.   The
frames need the style context to be up-to-date in order to lay out correctly.
Any mistake in lazy re-resolution would lead to incorrect display (at best).  It
may not always be clear what properties rely on other properties in the cascade
(especially because values in the style context can come from either CSS or HTML
attributes, and selectors can depend on the existence of HTML
attribute/values....)  So wouldn't you need to do a major portion of the
re-resolve work just to know what to mark dirty?

To sum up, I think it's too complex and error-prone, and may not save you very
much anyway.  But keep the creative ideas coming!

Comment 30

[rbs]

Indeed, the work of exactly determining and marking the StyleStruct that gets
dirty by a change looks like the same effort that it will take to answer Yes or
No to shaver's question: AttributeAffectsStyle()? So that energy may probably be
best spent there... Running out of other suggestions...

Comment 31

[Johnny Stenback (:jst)]

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

Comment 32

[Johnny Stenback (:jst)]

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

Comment 33

[rbs]

Activating the "Windows Task Manager" on Win2K also shows memory leaking away at
full speed...

Comment 34

[rbs]

Another testcase (note: here the caret in the textarea flashes differently from 
Nav4.x) http://www.dynamicdrive.com/dynamicindex4/flyimage.htm

Comment 35

[Eugene Savitsky]

http://www.bestdj.net/Dima.html - another one.

Comment 36

[Chase Tingley]

Possibly some good news... using 2001052310-STYLE (hyatt's stuff, bug 78695),
I'm seeing sustained 60-65% CPU on a P3/800 running Linux.  This seems like an
improvement compared to some of the other numbers floating around, though I have
no idea if it's actually related to the work he did.

Comment 37

[Marc Attinasi]

taking this... buster would be proud.

Comment 38

[Hixie (not reading bugmail)]

Testcases:
  http://www.f1-racing.ru/news/2001/0101.html
  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22446
  http://www.dynamicdrive.com/dynamicindex4/flyimage.htm
  http://www.bestdj.net/Dima.html
These are still slower than IE.

Comment 39

[Paul van Dam]

Also check:

http://bugzilla.mozilla.org/show_bug.cgi?id=64516

http://www.xs4all.nl/~pcvandam/dynobj2/do2test.html

100% cpu while draggin/scrolling, making it terribly slow..

Comment 40

[Paul van Dam]

Ignore first URL :P

Comment 41

[Stephan Tolksdorf]

Also check:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=45650
(A very simplified dhtml scrollbox (Bug #70156))

Comment 42

[lohphat]

There's another interesting "bug" here.  The page contents are in Cyrillic and
display fine, but the title is munged.

http://www.f1-racing.ru/news/2001/0101.html

Comment 43

[Aaron Kaluszka]

what the heck does that have to do with this bug?
you are describing bug 61676

Comment 44

[Markus Hübner]

http://www.world-direct.com/mozilla/moz_sliding.htm
Just click on the top-navigation to start the animation.

msie, opera and ns4.x are doing fine at this.
msie has finished after 1sec ... mozilla takes 6secs.
During the whole animation cpu usage is at 100%!

Comment 45

[Manfred Schneiderbauer]

cc'ing self.

Comment 46

[ArronM (:paper)]

Attachment: Setting Style Properties Slow / CPU Hogging

Comment 47

[Peter Lubczynski]

cc:ing some performance people

Comment 48

[Boris Zbarsky [:bzbarsky]]

http://web.mit.edu/bzbarsky/www/DOMAnimProfile.html is a profile of attachment
56446 [details]

The interesting thing I see in this profile is the 33% number for poll() and
3.4% number for select() (profiled under linux, with jprof, JP_REALTIME, 2msec
timer interval, and I just let this thing run for a while)

Comment 49

[Matthias Versen [:Matti]]

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

Comment 50

[Eugene Savitsky]

Please look at bug 116683. It may depend. It causing the same effect as this bug.

Changed URL. The old does not exist anymore. The new one is from the same sate
and the same.

Comment 51

[Jaime Rodriguez, Jr.]

Adding nsbeta1 keyword to all regressions so they *get some love* and attention.

Comment 52

[Marc Attinasi]

Bulk push to next milestone

Comment 53

[Marc Attinasi]

Perf --> 1.0

Comment 54

[Kevin McCluskey (gone)]

Moving to Moz1.1, nsbeta1-. Engineers are overloaded with higher priority bugs.

Comment 55

[Paul van Dam]

Yeah.. who uses DHTML anyway..

Comment 56

[Kevin McCluskey (gone)]

Moz 1.1

Comment 57

[Randell Jesup [:jesup] (needinfo me)]

This bug is helped considerably by the reflow tree branch (bug 129115)

Comment 58

[Paul van Dam]

I'm no expert, but I do see considerable performance increase when I update an 
input field with every DHTML animation-change. It almost seems that that 
triggers a page relayout, even though I put the input in a hidden layer.

Comment 59

[Paul van Dam]

Working example:

http://bosmonster.b2f.nl/scroll

Comment 60

[Markus Hübner]

Regarding comment #58
That's exactly what jesup reported in bug 117061 (see comment #9 and #10).
Hope this bug gets addressed soon.

Comment 61

[Boris Zbarsky [:bzbarsky]]

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

Comment 62

[Markus Hübner]

Reassigning since Attinasi no longer works for Netscape.

Comment 63

[Markus Hübner]

Filed an own bug about the style resolution optimization - bug 149216

Comment 64

[Greg K.]

Using FizzillaCFM/2002071208 to access the various testcases, CPU usage gets up
aruond 50%, but not near 95%. PC only?

Note that original URL can longer be accessed.

Comment 65

[Phil Schwartau]

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

Comment 66

[Phil Schwartau]

Here is a working URL from the duplicate bug 157903:

            http://bozman.net/glory/index.html

This produces a "snow effect" by dynamically moving <divs> around. 
From that bug's report:


------- Additional Comment_ #1 From Phil Schwartau 2002-07-17 11:06 ------- 

On my WinNT(SP6) 500MHz 128RAM, this takes up about 60% CPU in IE6.
But in Mozilla trunk 20020715xx, it pins the CPU at 100%.

In IE6 the snowflakes fall smoothly in microscopic increments.
In Moz the movements seem to coalesce and are very awkward-looking.



------- Additional Comment_ #2 From Johnny Stenback 2002-07-17 13:22 ------- 

While the page is loading I too see the weird movement of the snowflakes, but
once the page finishes loading the movement of the snowflakes is nice and
smooth. We do use 100% cpu tho...

Comment 67

[Matthias Versen [:Matti]]

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

Comment 68

[Matthias Versen [:Matti]]

-> next alpha

Comment 69

[Markus Hübner]

Can someone do a profile of
http://bozman.net/glory/index.html ?

Comment 70

[Taral]

15-20% CPU on my p4 1.8 winxp. No visible memory leak.

Comment 71

[Geoff Leach]

70% CPU. Red Hat 8. CVS build 25/3/2003. 


Configure arguments
--enable-svg --enable-crypto --enable-default-toolkit=gtk2 --disable-toolkit-gtk
--disable-toolkit-qt --enable-xft --enable-freetype2 --enable-cpp-rtti
--enable-cpp-exceptions --enable-extensions --with-system-jpeg
--with-system-zlib --with-system-png --with-system-mng

Comment 72

[Adam D. Moss]

Scary page. :)  40%(moz)+20%(X) = 60% CPU, 1180x937pix moz window,
linux/gtkfe/x86 750MHz athlon + gf2mx.

Comment 73

[Tarmo Järvalt]

WinXP SP1, 512 MB, 1800+ Athlon XP

http://bozman.net/glory/

* IE 6.0 SP1 average ~4-6% peaking sometimes ~20%

* Mozilla nightly rv:1.5a Gecko/20030604 average ~17%, peak ~20%, sometimes
dropping to 1-4%

* Opera 7.10 average ~35-40%


http://bugzilla.mozilla.org/attachment.cgi?id=56446&action=view

* IE average ~0%

* Mozilla average ~0%

* Opera average ~1%

Comment 74

[Christian 'CeeJay' Jensen]

I cannot detect this issue with Firefox 0.9/WinXp (please confirm) - Have it
been fixed by a patch to another bug ?

Oh .. btw the URL is invalid - I tried the http://bozman.net/glory/index.html
URL that was mentioned in the comments

Comment 75

[Stephen Anderson]

Build Gecko/20040623 Firefox/0.8.0+ CPU 90-95%
IE 6 CPU 25-35%

Comment 76

[Boris Zbarsky [:bzbarsky]]

This issue is quite present in current builds.  My development tree is _much_
smoother than current trunk is, and Opera is smoother still (all on Linux).  We
have quite a ways to go on this one.

Comment 77

[Adam D. Moss]

Hmm, what interesting goodies are in your development tree then? :)

Comment 78

[Boris Zbarsky [:bzbarsky]]

Mostly bug 230170, but also some other random stuff.

Comment 79

[José Jeria]

Replacing invalid url with working one

Comment 80

[Boris Zbarsky [:bzbarsky]]

OK.  On that testcase, I see us using about 30% CPU in a current Linux trunk
build.  That's less than Opera 8.0 beta.

Are people still seeing a too-large amount of cpu usage here?

Comment 81

[Bob Clary [:bc] (inactive)]

20-25% on a firefox 1.0/winxpsp2 build and a pentium m 1.7Ghz

Comment 82

[Adam D. Moss]

On a trunk firefox build I'm seeing 100% CPU usage and about 7 frames per
second.  The GIF animation on that page slows down noticably also.  Linux/x86,
GTK2, 750MHz Athlon.

Comment 83

[Bob Clary [:bc] (inactive)]

20-25% on a firefox trunk 2005-01-28/winxpsp2 build and a pentium m 1.7Ghz

Comment 84

[Boris Zbarsky [:bzbarsky]]

Odd... I see the same behavior with GTK2/XFT current SeaMonkey build -- about
30% cpu.  P3-733 here.

Comment 85

[Eugene Savitsky]

Mozilla 1.8a6, AMD Athlon 3200+, 512Mb, XP Pro - 50%.

Comment 86

[José Jeria]

Win XP, tested on 2 different computers, with same build (20050131):

P4, 3,2 Ghz, 768 MB:			0-4% CPU Usage
Intel Celeron, 2,39 Ghz, 512 Mb: 	100% CPU Usage

Comment 87

[Boris Zbarsky [:bzbarsky]]

Interesting.  How do the two graphics cards compare?

Comment 88

[José Jeria]

Fast computer has:
ATI Radeon 9800 XT
Specs: http://hardware.gamespot.com/ATI-Radeon-9800-XT-256MB-358-S-9-9

Slow computer has a build-in card (probably cheap):
Intel(R) 82845G/GL/GE/PE/GV Graphical controlor
Specs: http://support.intel.com/support/graphics/intel845g/sb/CS-009078.htm

Comment 89

[Boris Zbarsky [:bzbarsky]]

Yeah, that's almost certainly what makes the difference....

Comment 90

[Adam D. Moss]

I have an AGP GeForce FX 5200 with the latest linux drivers.

Comment 91

[Dimitrios]

My machine is a P4-2.25Ghz with Geforce 440MX video card and Firefox official
trunk build 20050207. Cpu usage is 30-50% on the testcase mentioned above
(bozman.net/glory/index.html), depending on the number of leaves on the screen.
But when I move the cursor, it jumps up to 90%.

With IE6-SP1, cpu usage is 0% when not moving the mouse and jumps up to 5%
otherwise.

Comment 92

[(mostly gone) XtC4UaLL [:xtc4uall]]

anyone could provide a new url or new testcase ?

Comment 93

[Cees T.]

Using Firefox 2.0.0.3 on K/Ubuntu 6.10 with 440 MB RAM.
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON XPRESS Series Generic
OpenGL version string: 2.0.6011 (8.28.8)

URL times out; comment 34 uses 13% of an Intel Celeron 2.8GHz; http://bugzilla.mozilla.org/showattachment.cgi?attach_id=22446 WFM; 
https://bugzilla.mozilla.org/attachment.cgi?id=45650 uses 80+% when scrolled fast;
http://www.world-direct.com/mozilla/moz_sliding.htm peaks the CPU;
https://bugzilla.mozilla.org/attachment.cgi?id=56446&action=view causes 37+-5% CPU usage; the other testcases are dead/gone.

This bug could be a duplicate of bug 139986 (that has an excellent testcase).

Comment 94

[Cees T.]

Or bug 186442, which has a snow testcase.

Comment 95

[Boris Zbarsky [:bzbarsky]]

In general, if "snow" testcases use different techniques (which they often do), they are different bugs.

We really should have copied the testcase into this bug; now that it's gone there's not much we can do with it, imo.

Comment 96

[Adam Hauner]

Content of original URL can be found in Web Archive, yes, with working snow effect (take some time to load whole page):
http://web.archive.org/web/20050206010210/http://bozman.net/glory/index.html
http://web.archive.org/web/20020802125844/http://bozman.net/glory/index.html

Comment 97

[Adam Hauner]

Attachment: JS of snow effect from webarchived page

Comment 98

[Boris Zbarsky [:bzbarsky]]

Any chance of attaching all the data needed?  Note that peformance can depend majorly on the exact CSS, DOM, and images being used, not just the JS...

Comment 99

[Adam Hauner]

Attachment: full page (glory.zip)

Comment 100

[Boris Zbarsky [:bzbarsky]]

Awesome!  Thank you!

Comment 101

[José Jeria]

CPU usage is about 25-35% using latest trunk on Windows 2000, Pentium 4, 3Ghz

Comment 102

[Zibi Braniecki [:zbraniecki][:gandalf]]

It's 10-16% on my Windows XP (Athlon X2 4800+).

It's 0% on latest webkit and IE7, and ~10% on latest Opera

Comment 104

[Ryan Jones-Ward [:sciguyryan]]

I can no longer reproduce this bug in the latest Minefield hourlies. The CPU usage does peak when scrolling the page but even that is not very severe.

I believe this bug has been fixed. If anyone still sees this please file a new bug with a testcase. Thanks.