279465 - Progress bar consumes a lot of CPU power

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jaap A. Haitsma]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)

When I for example send email and the progress bar for the smtp server shows up
my  processor usage goes up to 30%. (PIII 750MHz) which is a lot for just a
simple progress bar. I also see this when the progress bar in status bar is
active. It does not happen with the normal progress bar i.e. the one that just
goes from 0% to 100% but with the one where only a small part of the progress
bar is filled and that part is looped, i.e when it is at 100% it starts at 0% again


Reproducible: Always

Steps to Reproduce:

Comment 1

[limval]

Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.5) Gecko/20050206 Firefox/1.0
(Debian package 1.0+dfsg.1-5)

same happens to me.
Seems to be a problem with the progressmeter widget in "undetermined" mode.

Here are simple steps to reproduce it:

1. goto ftp://ftp.iinet.net.au/debian/debian-cd/woody-i386-1.raw
2. select Save.
3. go to the download manager window.
4. cancel this download.
5. retry this download.
6. repeat again with ftp://ftp.iinet.net.au/debian/debian-cd/woody-i386-2.raw
7. both progress bars are "undetermined", and take lots of CPU.

Comment 2

[Phil Endecott]

Just to give an example of how serious this is: while opening a large mailbox or
a message with a huge attachment from an IMAP server running on the same
machine, "top" shows Thunderbird taking ~55% CPU, X taking about ~25%, and the
mail server getting only ~7%.  If the mail server got 70% rather than 7% the
mailbox or message would open 10 times more quickly.

In comparison, Evolution, which displays a simple text "x% complete" message,
takes so little CPU while waiting for the server that it does not even register
on "top", and so it really does respond more quickly.

You are less likely to appreciate how serious this is if your IMAP server is on
a remote machine.

I see similar behaviour with Firefox's "throbbers", so I wonder if this is
actually the right component for this bug.

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Jaap A. Haitsma]

This problem still is there in the latest stable versions

Comment 5

[u88484]

Confirming on win2k

Comment 6

[u88484]

forgot to mention this also affects Firefox be it bffastback or regular
browsing; both are sped up when a progress/status meter is not present (ie Full
Screen mode)

Comment 7

[Martijn Wargers (dead)]

Well, this is an example of Firefox's progressmeter, it doesn't take much CPU on
my PC (4% using a Duron 600MHz):
https://bugzilla.mozilla.org/attachment.cgi?id=180061

Comment 8

[Phil Endecott]

(In reply to comment #7)
> Well, this is an example of Firefox's progressmeter, it doesn't take much CPU on
> my PC (4% using a Duron 600MHz):
> https://bugzilla.mozilla.org/attachment.cgi?id=180061

Martin, what version were you using to get that figure?

On my FF1.0.x it takes 56% CPU, and X takes another 9%.  This is a Celeron 500.
 It's an old PC, but generally more than fast enough for web browsing and email.
 If you're seeing this much lower CPU with a newer version, something has been
fixed.

--Phil.

Comment 9

[Martijn Wargers (dead)]

Attachment: testcase

I'm using 2005-10-02 trunk build. I'm using a Duron600MHz, 512MB, GeForce2MX
200 32MB.
With this testcase I get appr 4200ms as result with the cpu at 70%. 
It's a bit odd that cpu creeps up so fast when adding a few extra
progressmeters.
With 5 of these progressmeters, I also already begin to suffer from bug 280922.

Comment 10

[u88484]

9600ms and 98% cpu the whole test on amd k6-2 on win2k with 256mb ram. Only
programs open were Firefox and TB both sitting ideling except for the testcase
running.

Comment 11

[Martijn Wargers (dead)]

Attachment: Testcase2, using settimeout

This uses settimeout instead of setinterval. It's a bug slower for me, 4900ms
against 4200ms for the previous testcase, but I don't get to see bug 280922
with this one. cpu usage remains the same with this testcase.

Kurt, can you test this one too? Can you also compare how usable Firefox usage
is between the two testcases? (like switching tabs)

Comment 12

[u88484]

First testcase won't even let me switch tabs. Second testcase took 12097ms with
only Firefox and TB running and Firefox having google, and yahoo tabs open both
fully loaded and idle.

Comment 13

[Martijn Wargers (dead)]

Well, it's probably a xul layout problem, the moving of the <spacer> causes the
most cpu usage.

Comment 14

[Christian 'CeeJay' Jensen]

Moving the mouse also makes the animation go faster .. and at the same time the
CPU usage goes way up.

Comment 15

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I confirm this bug!!! With a veyr simple undeterminde progressmeter, I switch from Firefox eating 2 to 3% cpu to a rough 92% !!!!

Comment 16

[[e-mail]]

Helpful hint for extension developers: when you've finished with your
undetermined progressmeter, either change it back to a determined
progressmeter or make it hidden or remove it completely. Note: collapsed
is insufficient, as the progressmeter will continue to invisibly eat CPU.

Comment 17

[Boris Zbarsky [:bzbarsky]]

So when I run this locally (window width is 1000px, since that matters for the timings on this testcase), I get times on the order of 4100ms.  The minimal time this should take just due to the timeouts is 2667ms or so.

There's some obvious inefficiency in the binding; removing this brings the time down to about 3900ms.  Changing behavior slightly in a way that makes no difference in most cases but breaks if the progressmeter is resized while running brings the time to 3400ms.  Making most of the actual progressmeter stuff a no-op brings the time to 3200ms.  In the last case, the CPU meter is near 0; in the 3400ms case it's at about 70%; in all other cases it's near 100%.

In any case, this looks like the typical "DHTML" testcase, with time spent on security checks, XPConnect, restyling, etc...

A chrome testcase would actually be somewhat interesting, since the security checks would be different.

In any case, I have to wonder whether the progressmeter really needs to update every 10ms.  20 or 30ms might work just as well, imo.

Comment 18

[Boris Zbarsky [:bzbarsky]]

We really should consider addressing the other obvious inefficiency, though.  Just replace:

              spacer.height = stack.boxObject.height;
              spacer.width = stack.boxObject.width >> 2;
              spacer.left = spacer.width * position;
              position += 30 / (stack.boxObject.width + 600);

with:

              var width = stack.boxObject.width;
              var height = stack.boxObject.height;
              var spacerWidth = width >> 2;
              spacer.height = height;
              spacer.width = spacerWidth;
              spacer.left = spacerWidth * position;
              position += 30 / (width + 600);

Comment 19

[[e-mail]]

Attachment: 20ms

Changing the interval seems to make the most difference; optimizing the width (which I have done anyway) made a negligible difference. Initially my test case consumed ~55% CPU (Xvnc ~15%); with this patch I get ~25% CPU (Xvnc ~20%).

Comment 20

[jag (Peter Annema)]

Comment on attachment 235383 [details] [diff] [review]
20ms

Shouldn't that be |position += 7.5 / (width + 150);|?

Comment 21

[[e-mail]]

(In reply to comment #20)
>(From update of attachment 235383 [details] [diff] [review] [edit])
>Shouldn't that be |position += 7.5 / (width + 150);|?
Because I'm moving the bar half as often, I need to move it twice as far.

Comment 22

[jag (Peter Annema)]

Ah, right. I wonder, could these magic numbers (20, 15, 150) be expressed in terms of eachother, to make their relation more obvious?

Comment 23

[jag (Peter Annema)]

Actually, I guess that 20 isn't a magic number, it's just something we chose.

Comment 24

[Mike Connor [:mconnor]]

Comment on attachment 235383 [details] [diff] [review]
20ms

r=[e-mail]

Comment 25

[jag (Peter Annema)]

Comment on attachment 235383 [details] [diff] [review]
20ms

Patch is ok, but I'd still like to see that 15 and 150 explained.

Comment 26

[[e-mail]]

Fix checked in.

Comment 27

[Mike Schroepfer]

Comment on attachment 235383 [details] [diff] [review]
20ms

a=schrep for drivers for perf improvement fix.

Comment 28

[[e-mail]]

Fix checked in to the branch.