Thunderbird: high CPU usage from progress bars

Bug #109943 reported by Jan on 2007-04-25
62
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Confirmed
High
thunderbird (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: mozilla-thunderbird

When sending a simple and short email with Thunderbird via SMTP the CPU is used intensively. This seems not to be necessary. If the sending failed and an corresponding error message dialog appears, the CPU is still being used. When pressing ok to close the error dialog the CPU is fine. This suggests it might be related specifically to the progress bar. Such behavior is especially annoying on a laptop where you can hear the CPU usage because of a starting fan.

Assigned to Mozilla Team

Changed in mozilla-thunderbird:
assignee: nobody → mozilla-bugs
Day (day) wrote :

Same pb here. Ubuntu gutsy.

Matthew Woerly (nattgew) on 2008-01-27
Changed in thunderbird:
status: New → Confirmed
Jullian Gafar (jullian) wrote :

Still affects Intrepid. Is it ever going to be solved?

jullian@zelda:~$ uname -a
Linux zelda 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux

Alexander Sack (asac) wrote :

have you tried to "compact folder ..." for your sent and inbox folders? (right mouse click -> Compact)

Changed in thunderbird:
assignee: mozilla-bugs → nobody
status: Confirmed → Incomplete
Jullian Gafar (jullian) wrote :

It doesn't change. Still abnormal high processing while sending.

Alexander Sack (asac) wrote :

maybe its the progress bar that consumes CPU for you? Is there any graphic activity for you when you see this?

I can confirm this, Ubuntu 8.04, Thunderbird 2.0.0.19.

Casey (veg9000) wrote :

Same here, with Intrepid. This is with an IMAP account where the sent folder is on the server.

Thunderbird 2.0.0.19+nobinonly-0ubuntu0.8.10.1

The progress bar moves so I would say there's graphic activity.
How about an option to switch off any progress bars to save cpu/battery?

Alex Denvir (coldfff) wrote :

We are closing this bug report because it has not been updated for some time. Please reopen it if you have more information to submit, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in thunderbird (Ubuntu):
status: Incomplete → Invalid
Bartek (tschew) wrote :

Reopening because the bug still exists and the source is almost definitely the small progress bar at the lower right-hand corner of the Thunderbird window. To narrow it down I would propose for the people having the problem to report their graphics hardware and the cpu usage from top when the problem occurs.

I see:

thunderbird ~30-50%
Xorg ~20%

on an intel GM45 chipset

I would also rename the bug to reflect that it's not just when sending mail but also when getting new messages. (in short: whenever the progress bar is active)

Changed in thunderbird (Ubuntu):
status: Invalid → Incomplete

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a5pre) Gecko/20100426 Shredder/3.2a1pre

Symptom: any progress bar that appears seems to bring with it a pegged CPU core.

I suggest it's the progress bar code that is polling the CPU. If I send a message, and the send process fails for some reason, the progress bar continues to animate, while a new dialog box appears with a reason for error. Meanwhile, a CPU core is still pegged, even though there is no "real" work being done, just the progress bar animation.

I've noticed the high CPU core usage with *any* progress bar activity, not just the above example. For example, on this latest build, the progress bar in the lower right is attempting to complete while I type this bug report, I presume while it indexes for the first time (first time with /this/ build) my inbox,(>8000 messages). Meanwhile, my CPU graph shows one core in full usage.

Reproducible: Always

Steps to Reproduce:
Here is one method to get a status bar

1. Open Thunderbird.
2. Clear your password
3. Send a message
4. Type in an incorrect password
5. Note the CPU usage when it gives you the SMTP error dialog.

If it matters, I'm using IMAP, but again, I doubt that's the issue. I think it's the scroll bar code.
Actual Results:
When any progress bar is visible, a processor goes berserk.

Expected Results:
When any progress bar is visible, the CPU usage caused by the progress bar should be pert near zero.

These bugs may be relevant, or may turn out to be duplicates. I couldn't quite tell from the descriptions:

https://bugzilla.mozilla.org/show_bug.cgi?id=367431
https://bugzilla.mozilla.org/show_bug.cgi?id=538283
https://bugzilla.mozilla.org/show_bug.cgi?id=543422

Kevin Hunter (hunteke) wrote :

I've had this problem for ages (3+ years) with Thunderbird. I'm now in triage mode as I've just installed Lucid and I've been tracking down lots of little annoyances.

For the record, Thunderbird 3 has the same issue. I'll point out that it's not *just* the little progress bar, but /any/ progress bar that Thunderbird presents.

$ uname -a
Linux hani 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux

$ lspci | grep -i vga
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8400M GS] (rev a1)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04 LTS
Release: 10.04
Codename: lucid

Another reason why I think the issue is specifically with the progress bar code and not, for example, the Gloda code: this issue has been around since at least Thunderbird v1.5. As referenced by Bug 543422, Gloda may *also* be a CPU hog, but I think the this merits it's own bug report.

Kevin Hunter (hunteke) wrote :

I couldn't find an upstream bug report specifically addressing the progress bars and CPU usage, so I created one:

https://bugzilla.mozilla.org/show_bug.cgi?id=562977

Changed in thunderbird (Ubuntu):
status: Incomplete → Confirmed
Kevin Hunter (hunteke) wrote :

Marking as confirmed since it seems a number of people have noticed this issue.

Kevin Hunter (hunteke) on 2010-04-30
summary: - Thunderbird: high CPU while sending email
+ Thunderbird: high CPU usage from progress bars
description: updated

Kevin, I don't put any stock in those other bugs.

Are you seeing this mainly with trunk build? ( Trunk builds are currently badly broken.)

Do you see this issue with indexing disabled? (restart after disabling)
If it's only with indexing enabled, can you follow the first two steps at
https://developer.mozilla.org/en/Thunderbird/Gloda_debugging, this should show
you errors in the error console.

Index disabled, restarted. Problem persists.

I checked with both the stock Ubuntu Lucid version (v3.0.4) and with the trunk version built 4 days ago (2010 Apr 26).

I recreated the issue as I described above, removing my saved password, sending an email, and then pausing to observe the effects when it asked for my password. High CPU usage until I canceled the "Give me your password" dialog.

$ dpkg -l thunderbird | cat
ii thunderbird 3.0.4+nobinonly-0ubuntu4
$ ps ufax | grep thunderbird
mcp 2166 31.1 18.8 378524 89864 ? Sl 10:40 17:32 \_ /usr/lib/thunderbird-3.0.4/thunderbird-bin
$ strace -p 2166 2>&1 | head -n 20
Process 2166 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
gettimeofday({1273620600, 759410}, NULL) = 0
read(19, "\372", 1) = 1
gettimeofday({1273620600, 759608}, NULL) = 0
gettimeofday({1273620600, 759691}, NULL) = 0
write(20, "\372", 1) = 1
gettimeofday({1273620600, 760352}, NULL) = 0
gettimeofday({1273620600, 760412}, NULL) = 0
gettimeofday({1273620600, 760465}, NULL) = 0
futex(0xb75e5588, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0xb75e5584, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
gettimeofday({1273620600, 760628}, NULL) = 0
gettimeofday({1273620600, 760763}, NULL) = 0
gettimeofday({1273620600, 760819}, NULL) = 0
gettimeofday({1273620600, 760880}, NULL) = 0
gettimeofday({1273620600, 761036}, NULL) = 0
gettimeofday({1273620600, 761090}, NULL) = 0
gettimeofday({1273620600, 761149}, NULL) = 0
gettimeofday({1273620600, 761212}, NULL) = 0
gettimeofday({1273620600, 761851}, NULL) = 0

It looks like the animation code is doing something very inefficient if it's calling gettimeofday() thousands of times per second.

John McPherson just performed a perhaps telling strace of Thunderbird 3.0.4:

https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/109943/comments/15

The telling bit from his comment:

It looks like the animation code is doing something very inefficient if it's calling gettimeofday() thousands of times per second.

From there, here's a similar analysis on May 12th's nightly build:

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.3a5pre) Gecko/20100512 Shredder/3.2a1pre

----------
$ ps -elF | grep thunderbird
0 S kevin 27405 26060 10 80 0 - 99236 poll_s 81960 1 15:06 pts/0 00:01:33 ./thunderbird-bin
0 S kevin 30204 29053 0 80 0 - 1904 pipe_w 916 0 15:20 pts/2 00:00:00 grep --color=always thunderbird

$ time strace -p 27405 2>&1 | head -10000 | grep gettimeofday | wc -l
3803

real 0m2.532s
user 0m0.200s
sys 0m0.440s
----------

That's almost 4,000 requests for gettimeofday() in 10,000 lines retrieved by strace, all in 2.5 seconds. The question is why does some piece of code need to know gettimeofday several thousand times per second?

Note that to recreate this, the same trick of "forgetting" the password when sending a message was used. Also note that indexing is *still* disabled. No Gloda.

Peter, Nir
Does this reproduce in your environment?
And even if it doesn't, any thoughts or advice?

Kevin as a practical matter - is it at 100% during the entire time the progress bar is animated?

I have 2 cores on my machine. Speaking as an end-user, yes, a single core is pegged at 100% during the entire time the progress bar is active.

Chris Olin (chris.olin) wrote :

Process 8697 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 1
gettimeofday({1284636702, 520915}, NULL) = 0
read(19, "\372", 1) = 1
gettimeofday({1284636702, 521423}, NULL) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{"\200\1\2\0\377\0\0\0", 8}, {NULL, 0}, {"", 0}], 3) = 8
poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "\1\3_\271\0\0\0\0\376\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0\0\332\273\277\0\0\0\0", 4096) = 32
read(3, 0xb755c058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1284636702, 522628}, NULL) = 0
gettimeofday({1284636702, 522844}, NULL) = 0
gettimeofday({1284636702, 523012}, NULL) = 0
read(3, 0xb755c058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1284636702, 523400}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=37, events=POLLIN}, {fd=24, events=POLLIN}, {fd=18, events=POLLIN}, {fd=71, events=POLLIN}, {fd=41, events=POLLIN}, {fd=19, events=POLLIN}], 13, 0) = 0 (Timeout)
gettimeofday({1284636702, 523785}, NULL) = 0
gettimeofday({1284636702, 523969}, NULL) = 0
read(3, 0xb755c058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1284636702, 524259}, NULL) = 0

Kevin, do you still see this problem in version 3.1?
Do one of the bugs in comment 0 really describe your problem well?

(In reply to comment #7)
> Kevin, do you still see this problem in version 3.1?

Yes, but not nearly as badly. Now the CPU is about 20%, not 100%. To be clear, I believe from personal experience that animating a simple scroll bar and waiting for user input ought to register at 1% or less CPU utilization.

Performing a similar analysis as above, with Thunderbird waiting for a password (and consequently with a scroll bar going), yields the number of gettimeofday calls to be in the same vicinity (3,500 to 4,000 calls) in 10,000 lines retrieved via strace, and a much more consistent 2,275 POLL events.

Note that I just downloaded and tested Mozilla's copy of 3.1.7 (not my distribution's).

> Do one of the bugs in comment 0 really describe your problem well?

No. I wasn't sure at the time I wrote this bug report, but I became more confident later.

with trunk Thunderbird on windows, I see steady cpu usage of 5-30% (avg 9%) when any modal dialog box is up (error, password, etc). Thus, I suspect this is a duplicate.

when NOT logged in to imap account and no dialog box left open, ~2% (new bug?)

when logged in to imap account, and no dialog box left open, ~0%

I encountered this issue with 64-bit Thunderbird 5.0 on Linux (Debian). When the progress bar oscillates between left and right, CPU usage increases so that one of CPU cores is at 100%.

For now, I downgraded to TB 3.1.11, that doesn't show this issue or, at least, not to such an extent.

Tsu, Kevin, does CPU go down substantially if you start thunderbird in safe mode? (as it does in Bug 693852)
ref: http://support.mozillamessaging.com/en-US/kb/safe-mode

I have just updated the original test with a stock (direct from mozilla.org) copy of Thunderbird, version 7.0.1 (64-bit).

Answer: no. It remains high, between 20% and 50% of a core.

That other bug sounds related, and I would not be surprised if the buggy code is at least partially shared.

Thunderbird 8.0 also suffers from this bug.

This has been happening to me for years, and still happens in 12.0.1. I'm pretty surprised this hasn't gotten more attention. I've had cases where it completely pegs a core- 99 or 100%.

This was the only reason I left TB and used Evolution (in Gnome).

As of yesterday, I've gotten fed up with the resource hogishness and stability issues of the default Ubuntu window and desktop managers. I've now installed and configured OpenBox.

Where I was seeing this issue 3 days ago (albeit not as pronounced as once-upon-a-time), I'm now do not notice anything. Other than a 4 or 5 second wait to quit TB, things are right-zippy, with no (known) loss of functionality. I don't know how to confirm, but this certainly leads me to suspect an interaction between Thunderbird and Gnome and Unity. (And I believe KDE too, but it's now 4 years since I last tried KDE ...)

Another data point.

(In reply to Kevin Hunter from comment #16)
> As of yesterday, I've gotten fed up with the resource hogishness and
> stability issues of the default Ubuntu window and desktop managers. I've
> now installed and configured OpenBox.

Err, to clarify what I think you may be focusing on, the pegged cores were very much attributable to TB (as evidenced by Comments #4 and #8, and my personal observations through ps and htop, etc.), not to the the various Window/Desktop managers.

For purely non-TB reasons, I switched to OpenBox: my computer /really/ bogged down after I installed Ubuntu 12.04 (fresh install -- not upgrade -- if it's of use) on my machine last week. (This is still the same hardware as when I started this bug report.) The speedup of Thunderbird was a happy coincidence, and was not an intentional reason for my switch.

TB definitely still has a performance issue, but one that may be exacerbated by the interaction between the more well-known WMs and DMs.

Changed in thunderbird:
importance: Unknown → Low
status: Unknown → New

there is also activity manager.

<Archaeopteryx> wsm: seem like it starts here: http://mxr.mozilla.org/comm-central/source/mail/components/activity/modules/autosync.js#283
<Archaeopteryx> and onProgressChange gets called too much: http://mxr.mozilla.org/comm-central/source/mail/components/activity/content/activity.xml#485
<wsm> Archaeopteryx: see also https://bugzilla.mozilla.org/show_bug.cgi?id=742697#c14
<firebot> Bug 742697 nor, --, ---, acelists, NEW, SMTP connection progress bar causes high CPU usage
<wsm> how do you know it is called too much?
<Archaeopteryx> just a guess because i see no throtteling code. autsync's comment says it want to prevent event overflow, but it don't see bundling messaes per account at http://mxr.mozilla.org/comm-central/source/mail/components/activity/modules/autosync.js#249 which calls setProgress. you could verify with logging enabled, onDownloadStarted logs in the first lines

That is the question. I have not yet found if there is any throthling or how often these onProgressChange events are fired. I should probably get the time inside the handler and dump it out to see what happens.

Wayne can you come up with good STRs to get a progress bar repeatedly without downloading new messages? So that we can debug the code.

(In reply to :aceman from comment #22)
> Wayne can you come up with good STRs to get a progress bar repeatedly
> without downloading new messages? So that we can debug the code.

bug 791535 is a different situation, but is reproducible.
I assume bug 584643 is also reproducible.

collection of related bugs - https://bugzilla.mozilla.org/buglist.cgi?list_id=5125237;short_desc=progress%20activity%20barber%20spin%20spinner%20spinning;field0-0-0=short_desc;type0-0-1=anywordssubstr;field0-0-1=short_desc;resolution=---;query_format=advanced;short_desc_type=anywords;value0-0-1=indicat%20throb;type0-0-0=anywords;value0-0-0=meter%20bar%20pole;product=MailNews%20Core;product=Thunderbird

That query is not that good, from 21 bugs there are about 3 about this problem. You should probably add 'CPU' as a needed word.

(In reply to :aceman from comment #24)
> That query is not that good, from 21 bugs there are about 3 about this
> problem. You should probably add 'CPU' as a needed word.

sorry, quite right. I was mainly being hasty/lazy and I didn't mean to imply ALL are related. Looks to be about 1/3. Most relevant are bug 791535 and bug 742697

I was also being loose because a few bugs which don't cite CPU still are likely impacted. for example bug 47024, bug 584643

Changed in thunderbird:
importance: Low → Medium
status: New → Confirmed
Maximilian Haupt (0x7f) wrote :

hi guys.
i also experienced the issue, but i think i found the reason. in my case, the cpu usage is dependent on the gtk theme.
when switching the gtk theme to Clearlooks using:
$ gtk-theme-switch2 /usr/share/themes/Clearlooks
the cpu usage of X immediately jumps to 100%. but when switching to a different theme, e.g.:
$ gtk-theme-switch2 /usr/share/themes/Adwaita
with progress bar in status bar still active, the cpu usage immediately drops ~9% (still not 0% though) and thunderbird is way more responsive then.
imho, this looks like the issue is either inside the theme code itself or gtk code the themes are using.
hope this helps.

Recent profile http://people.mozilla.org/~bgirard/cleopatra/?1387475933880#report=1757ae9e3f70bc2dff02d261c2782ebdba77872e done under conditions of gmail stuck on "Downloading m of n All Mail" (bug 816327)

The amount of time spent painting is obscene (screen shot of profile to follow)

Holy crap, yes, we're spending a *lot* of time painting in that profile. What is being drawn during this sluggishness?

Created attachment 8350260
profiler - TB All mail gmail CPU throbber profiler from.png

What was being displayed on screen during this?

Created attachment 8350262
TB gmail up to date progress bars

screen shots of progress bar.

Note, apparently CPU can be way higher than 20% depending on type of activity. In the case of waiting for gmail, I'm seeing 60-100% CPU used by Tbird.

N.B. there may be differences in throbber resource usage depending on OS, as suggested in Bug 854093 - Indeterminate progress bar takes entire CPU.

Supposedly fixed:
Bug 304147 - progressmeter in undetermined mode does not work in Mac OS X
Bug 420254 - thunderbird often uses ~10% cpu when idle for no apparent reason
Bug 432028 - Undetermined progressmeter timer isn't stopped, causing high CPU load
Bug 586216 - Animated widgets have one timer per widget
Bug 587876 - Undetermined progress bars should use mozRequestAnimationFrame
Bug 704171 part 1. Stop using the no-argument form of mozRequestAnimationFrame in our chrome

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

(In reply to Mike Conley (:mconley) from comment #27)
> Holy crap, yes, we're spending a *lot* of time painting in that profile.
> What is being drawn during this sluggishness?

Does this contradict comment 32's bug list?

And what about bug 658829 and bug 729649 (both landed in early 2013) cited in bug 791535?

Does anybody still see this? With TB32, in Win XP I can't see the high CPU usage any longer. Via DOM Inspector, in TB main window (chrome://messenger/content/messenger.xul) I found <statusbarpanel id="statusbar-progresspanel"> where I set collapsed="true" to uncover the status bar progress meter. Then in <progressmeter id="statusbar-icon"> I set mode="undetermined". The progress bar began spinning without much CPU usage. So the progressbar alone doesn't seem to be the culprit. If we can find the CPU usage in other scenario, maybe something else is contributing to it.

As of v24.5, running on Ubuntu 13.10 (64bit) with Openbox, I no longer see gettimeofday calls in the strace output. TB is still polling like mad, but is at least efficiency polling. From an strace output like above, I now see:

  (11.6%) futex
  (27.4%) poll
  ( 4.0%) read
  (45.3%) recvfrom
  (11.7%) writev

And no gettimeofday. So, from the reporter, who has unfortunately changed the desktop he uses (see comments 16, 17, and 18), I no longer see this. Meanwhile, we still need input from someone running Gnome and Unity, I think.

This bug still exists. When the SMTP server does not respond (e.g, with misconfigured IP address setting),
I get 12-13% CPU load in my i5 macbook until the connection timeouts.

Thanks Wayne for bringing attention back also to this bug.

I can confirm that the bug still exists with the latest released TB version 31.3.0 with a cpu usage increase of about 12-13% on my Macbook Air. As I wrote recently in response on your request regarding the (likely related) bug 919485, unfortunately I cannot afford the time to install the trunk version and use profiling tools. Yet anyone interested could do for himself easily, since this bug can be reproduced in a straightforward way: put any garbage IP address as e.g. the IMAP (or POP or SMTP) server name and try receiving (or sending, respectively) emails.

I suspect that this waste of CPU (and battery on mobile devices!) is due to the same careless chunk of code performing a busy loop somewhere deep in Mozilla's TCP client connect implementation.

BTW, the title of this bug report is misleading, as it is too narrow: the misbehavior also occurs without any progress bar being shown, e.g., when trying to fetch emails.

Here is a trace while copying emails between folders on an IMAP server. Some work is actually being done, but there seems to be a lot of time spent in
Paint::PresShell::Paint
nsLayoutUtils::PaintFrame
nsDisplayList::PaintRoot

https://people.mozilla.org/~bgirard/cleopatra/?1418817484580#report=f2ec94e59158f41a3723d4d2d517587d1476ab41

WAG: Just a guess. Go to about:config and set the following preferences:
layers.acceleration.disabled -> true
layers.offmainthreadcomposition.enabled -> false

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

(In reply to David von Oheimb from comment #39)
> Thanks Wayne for bringing attention back also to this bug.
>
> I can confirm that the bug still exists with the latest released TB version
> 31.3.0 with a cpu usage increase of about 12-13% on my Macbook Air....
>
> I suspect that this waste of CPU (and battery on mobile devices!) is due to
> the same careless chunk of code performing a busy loop somewhere deep in
> Mozilla's TCP client connect implementation.

David, can you do a performance profile during a period of high CPU using the procedure at https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Thunderbird which uses Firefox as the recorder

- follow instructions at https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Thunderbird
- after connect, pick "main"
- click "Performance" in the developer tool menu
- click "start recording performance" in the center
- do some actions in thunderbird which cause the problem or behavior to be recorded
- click "stop recording performance" in the center
- click "Save" one the left
- email the json file or attach to this bug report

Created attachment 8824696
TB 45.6.0 high CPU load when connecting to unreachable IMAP server

Here is the requested performance profile with TB 45.6.0 on a Mac.
(The setup for getting it was a bit involved, using both FF and TB, but ok.)

Note that anyone can easily reproduce this CPU misuse:
Just set the IMAP Server Name of some account to an unreachable IP address like 1.2.3.4 and try getting emails from there.

This bug is apparently very low-level in the Mozilla network layer and has a number of related bug reports touched again recently also for FF.

High CPU usage seems to be caused by status bar animation.

Quick fix for me (works on Ubuntu) is to disable the status bar (for now).

Possible fix for THunderbird team: Remove this animation, and possibly the entire current animation subsytem, and replace all progress bar animations with something simpler, as I suspect that possibly all animations currently use high CPU usage, but on a decent net connection they do not display for very long (Jut a thought)

(In reply to :aceman from comment #35)
> Does anybody still see this? With TB32, in Win XP I can't see the high CPU
> usage any longer. Via DOM Inspector, in TB main window
> (chrome://messenger/content/messenger.xul) I found <statusbarpanel
> id="statusbar-progresspanel"> where I set collapsed="true" to uncover the
> status bar progress meter. Then in <progressmeter id="statusbar-icon"> I set
> mode="undetermined". The progress bar began spinning without much CPU usage.
> So the progressbar alone doesn't seem to be the culprit. If we can find the
> CPU usage in other scenario, maybe something else is contributing to it.

I seem to be getting conflicting data here. I did the same on a fresh profile and CPU went up to nearly 20%. The same happened when I used DOMi to add a new progressmeter element without any eventlisteners and such connected to it as long as the mode is set to undetermined. In fact, it even reproduces in Firefox nightly for me when I do the following in browser console:

var parent = window.document.getElementById("urlbar")
var progress = gBrowser.ownerDocument.defaultView.document.createElementNS("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul", "progressmeter");
progress.setAttribute("mode", "undetermined");
parent.appendChild(progress);

Could someone confirm that last bit to make sure it's not just me? If so, then the only thing Thunderbird can do is to work around by not using undetermined mode at all..

One more observation: using html:progress takes about 1/2 of the CPU that xul:progressmeter takes when animating.

I can confirm that this still happens for me in Debian Sid, thunderbird 52.2.0
The CPU usage goes up quite a bit, actually enough to make the fans kick in.
@zayne.a Can you please provide a bit more detail in how you do that? I tried to googling, without much luck.

(In reply to kwang.m.yi from comment #48)
> I can confirm that this still happens for me in Debian Sid, thunderbird
> 52.2.0
> The CPU usage goes up quite a bit, actually enough to make the fans kick in.
> @zayne.a Can you please provide a bit more detail in how you do that? I
> tried to googling, without much luck.

View > Toolbars > Status Bar

(In reply to David von Oheimb from comment #44)
> ...
> Just set the IMAP Server Name of some account to an unreachable IP address
> like 1.2.3.4 and try getting emails from there.
>
> This bug is apparently very low-level in the Mozilla network layer and has a
> number of related bug reports touched again recently also for FF.

Correct, Firefox gets the same issue. Perhaps a different bug, if the progress meter doesn't spin or your profile is different from the one Merike collected

(In reply to Philip Chee from comment #41)
> WAG: Just a guess. Go to about:config and set the following preferences:
> layers.acceleration.disabled -> true [HWA disabled]
> layers.offmainthreadcomposition.enabled -> false

Note, we've seen a variety of behavior with HWA disabled or enabled. For example, in bug 1267662 HWA disabled improved performance on a Mac

Merike, on what OS did you profile?

Note, from bug 781535 comment 24
(In reply to <email address hidden> from comment #22)
> Bug 658829 changed the way undetermined progress meters were painted on
> Windows from an XBL implementation to a native implementation. Linux still
> uses the XBL implementation for undetermined progress meters though.

The linux side is bug 854093 - Indeterminate progress bar takes entire CPU - in Widget: Gtk

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #51)
> Merike, on what OS did you profile?

Linux.

I can't reproduce this using the Ubuntu Thunderbird 52.3.0 on Ubuntu 16.04

52.6.0 (64-bit) on Ubuntu 18.04. On both gnome on Xorg and gnome on Wayland the progress bar uses 100% of one of my CPUs.
I know that if there is no other task a modern CPU tends to be in sleep mode most of the time (which makes the only task automatically reach 100%). But the progress bar also drains my battery in ca. 40 minutes and makes the CPU fan go haywire => it seems to be hideously inefficient.

@WaltS48: I guess I found out why this wasn't reproducible: There are 2 progress bars:
 * the one that is shown if the percentage of progress is known and
 * the one that is shown to indicate that an activity of unknown duration is in progress.
Only the latter one uses 100% of one CPU.

The drawback is: As soon as the network connection drops as you go mobile thunderbird's next attempt to connect to a server is likely to trigger the "activity of unknown duration" type progressbar - and to rapidly drain the accumulator if the mobile device.

Perhaps the activity indicator that has the problem should be better referenced to as "throbber" as a 2nd thought....

Changed in thunderbird:
importance: Medium → High
PeterPall (peterpall) wrote :

Thunderbird 60.7.0 still shows this problem.

What hope do we have to get away from indeterminate xul:progressmeter for linux (ref comment 47) ?
... for all our dialogs. Unsure if same issue exists anywhere in calendar-land (see "see also" links)

xul:progressmeter was converted to html:progress. But looks like it's still reproducible at least on linux.
In scratchpad or console, do

document.getElementById("tabmail-container").appendChild(document.createElementNS("http://www.w3.org/1999/xhtml", "progress"));

... and check CPU usage. For me it goes to around 20% and stays there.

Can also reproduce on Firefox nightly. There in the Developer Tools | Console

document.getElementById("urlbar").appendChild(document.createElementNS("http://www.w3.org/1999/xhtml", "progress"));

The only difference is that there it jumps from listing Firefox to "GPU process" and back. It's still Firefox causing it.

There's only a few which are indeterminate and they're important for providing feedback to the user that something is happening. I think the best solution, if any, is to chase the toolkit people to fix their widget. FWIW I've not had a problem with this thing for years but it probably does use more CPU than necessary, about 6% of a CPU for me.

Thanks for the info.

To reemphasize the big problems: a) even at modest amounts of CPU, it sucks battery life, b) at modest amounts (above 5-10%?, I forget the range) it impacts responsivesness when getting new mail, c) to make it worse we have (or at least have had) situations where the progress meter lingers, and even sometimes never goes away due to other brokenness so the CPU usage can be continuous.

(In reply to Geoff Lankow (:darktrojan) from comment #58)
> ... I think the best solution, if any, is to chase the toolkit people to fix their widget.

So far after 10 years in bug 854093 that hasn't worked out so well for linux. (or do we need something else?) Does someone know stransky or do we have some other friend?

On the windows side this required aceman and our friend Neil in bug 658829 (ref bug 791535 comment 19). But even there we still might have an edge case per bug 658829 comment 97.

In , nh2 (nh2) wrote :

Thunderbird 68.2.1 on Linux, I can confirm that this issue still exists, with createElementNS() as given above, and the SMTP sending progress bar from bug 742697, and the IMAP loading progress bar in the status bar when switching between folders.

15-20% CPU usage.

In , nh2 (nh2) wrote :

How can you match the generated <html:progress> tag with userChrome.css ?

I'd like to style it differently to check how the performance behaves, or hide it, but I don't know how to match it, only its parent `#statusbar-progresspanel`.

In , nh2 (nh2) wrote :

**Workaround:**

I found that disabling the indeterminate progress progress bar is not enough; the spinning throbber in the tab is also responsible for CPU usage.

I'm using the below in my Thunderbird profile folder's `chrome/userChrome.css` to disable both, resulting in the 15-20% CPU usage disappearing:

    @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

    /* nh2: Progress bar CPU usage fix. */
    /* For some stupid reason we can't match the html:progress that's the first child of this container.
       See https://bugzilla.mozilla.org/show_bug.cgi?id=562977#c61
       So we can't style the progress bar so that it does doesn't get shown only when
       indeterminate (which takes the most CPU), or style it to render faster.
       So for now we hide the entire parent container, thus getting rid of the progress bar entirely.
    */
    #statusbar-progresspanel {
      display: none;
    }

    /* nh2: Tab throbber animations also take a lot of CPU; hide them.
       Unfortunately I didn't find a way to replace them by a static image.
    */
    .tab-throbber[busy] {
      display: none !important;
    }
    .tab-throbber[progress] {
      display: none !important;
    }

This user chrome is a real battery saver! Thanks! ...and the throbber in the mouse pointer still tells me if thunderbird is busy.
---
If I understand this right we now have 2 things that are rendered in the same thread and that use 100% of one CPU (indicated as 50% of the CPU power of a 2-CPU-System, 20% of the CPU power of a 5-cpu-system and 12,5% of the CPU power of an 8-cpu one) if they get the chance of doing so. ...or was the progress meter a Red Herring and it was only the throbber all along?

100% of one CPU normally doesn't indicate that something is amiss: The CPU could be asleep 99% of the time and be busy 1% of the remaining time. But the battery drain throbber+progress meter and generate seems to indicate that the CPU won't sleep while there is indeterminate progress...

Gunter, you could only apply the rule for #statusbar-progresspanel and check how the CPU usage is with only the throbber spinning.

In , nh2 (nh2) wrote :

I have already tested that.

* Only throbber: ~15-20% CPU usage
* Only progress bar: ~15-20% CPU usage
* Both throbber and progress bar: ~15-20% CPU usage
* Both disabled: no CPU usage

@Gunter: I measured CPU usage on Linux with `htop`, where the percentage is always relative to 1 core. 15% means 15% of 1 core. Using full 2 cores would show up as 200%.

> 100% of one CPU normally doesn't indicate that something is amiss: The CPU could be asleep 99% of the time and be busy 1% of the remaining time.

I don't understand this sentence. If the CPU is asleep 99% of the time, CPU usage in `htop` should show up as roughly 1%, not 100%.

(In reply to Niklas Hambüchen from comment #65)
> I have already tested that.
>
> * Only throbber: ~15-20% CPU usage
> * Only progress bar: ~15-20% CPU usage
> * Both throbber and progress bar: ~15-20% CPU usage
> * Both disabled: no CPU usage

Strange that both together use the same CPU like when only one is active.

Please could you try
```
.tab-throbber[busy] {
  list-style-image: none !important;
}
```
Then I can see if the animated PNG is the cause of the CPU usage.

In , nh2 (nh2) wrote :

Yes, `list-style-image: none !important;` also fixes it.

> Strange that both together use the same CPU like when only one is active.

I don't find that strange: Using either progress bar or animated PNG throbber, the screen now has to be drawn at many frames per second. Once you have to redraw, redrawing a bit more doesn't make a big difference.

Separetely: Also useful to know for posterity, the upgrade from Thunderbird 60 to 68 made the indeterminate progress bar a lot more jumpy (it looks like around 10 FPS while the original was much smoother) - but to my surprise that increased jumpiness still didn't reduce CPU usage a lot.

Richard, given the most recent bug comments, is a Thunderbird solution possible without addressing bug 854093?

In , Nl0 (nl0) wrote :

I really wonder why even after 11+ years this is still not fixed and
reporters like me have been bugged multiple times with needless Needinfo requests?!?

As I wrote several times over several years at several places in this bug tracker:
The problem is easily reproducible with any TB version (meanwhile including 78.4.2.).

Again: just enter an IP address such as 1.2.3.4 as the server name/address.
Then try fetching emails. Until this timeouts,
the progress bar moves forth and back with significant CPU load (10% of one core on my current Linux machine).

In TB 78 we use now the HTML progressmeter. I hope this helps a bit.
I tried the FX approach with using a SVG as throbber but I see on my system no difference to the PNG throbber with 2% CPU.

For the throbber I could create a patch.

In , Nl0 (nl0) wrote :

> In TB 78 we use now the HTML progressmeter. I hope this helps a bit.

Your hope is not fulfilled.
I've just tried TB 68 in comparison with Tb 78 - and got the same 10% CPU load on both.
Again - why don't you IT professionals try out such things yourself?!?

I'm a voluntary contributor and don't need such comments. It's also not very helpful when I see only 1% difference when I test it.

In , Nl0 (nl0) wrote :

One actually does not need to be an IT professional to see that for the given issue there is no improvement with FB 78.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.