Ryan Johnson Reporter
	Description • 13 years ago

Checking email over a slow/overloaded wireless connection can take 90 seconds or longer, with CPU usage hovering at 40-80%. This destroys my laptop's battery life, especially if a connection times out; sometimes I have to close TB to make it stop burning CPU. The same can happen if an email server is down or not responding properly.

	Ryan Johnson Reporter
	Comment 1 • 13 years ago

I just noticed: while submitting this bug over the same slow/overloaded wireless connection mentioned above, Firefox displayed the same behavior (40-80% cpu util while waiting for a response from bugzilla). Perhaps this bug is common to both?

	WADA:World Anti-bad-Duping Agency
	Comment 2 • 13 years ago

(In reply to Ryan Johnson from comment #0)
> Checking email over a slow/overloaded wireless connection can take 90
> seconds or longer, with CPU usage hovering at 40-80%.

SSL(pop3/imap/smtp with SSL) only problem? No problem if non-SSL?

(In reply to Ryan Johnson from comment #1)
> I just noticed: while submitting this bug over the same slow/overloaded
> wireless connection mentioned above, Firefox displayed the same behavior
> (40-80% cpu util while waiting for a response from bugzilla).

Submitting of bug to bugzilla.mozilla.org is upload of data by POST via HTTPS:(HTTP with SSL, sender of TCP=Fx, receiver of TCP=server when POST process).
No problem if non-SSL site(HTTP:)?

It may be frequent packet loss followed by re-transmission.
When(with which build of Tb/Fx, specific date, after upgrade, ...) did your problem start to occur?
Can small network.tcp.sendbuffer(default=131072) such as 4096, 8192 be a workaround for bug submitting or comment posting at bugzilla.mozilla.org?

	Wayne Mery (:wsmwk)
	Comment 3 • 13 years ago

Ryan, please reply to comment 2. Thanks

	Ryan Johnson Reporter
	Comment 4 • 13 years ago

(In reply to WADA from comment #2)
> (In reply to Ryan Johnson from comment #0)
> > Checking email over a slow/overloaded wireless connection can take 90
> > seconds or longer, with CPU usage hovering at 40-80%.
> 
> SSL(pop3/imap/smtp with SSL) only problem? No problem if non-SSL?
All four of my accounts are SSL, but I can't disable it verify that non-SSL works better.

> (In reply to Ryan Johnson from comment #1)
> > I just noticed: while submitting this bug over the same slow/overloaded
> > wireless connection mentioned above, Firefox displayed the same behavior
> > (40-80% cpu util while waiting for a response from bugzilla).
> 
> Submitting of bug to bugzilla.mozilla.org is upload of data by POST via
> HTTPS:(HTTP with SSL, sender of TCP=Fx, receiver of TCP=server when POST
> process).
> No problem if non-SSL site(HTTP:)?
I'll have to get back to you if I see a non-SSL upload taking a long time -- it doesn't happen to me that much.
 
> It may be frequent packet loss followed by re-transmission.
> When(with which build of Tb/Fx, specific date, after upgrade, ...) did your
> problem start to occur?
I noticed just during the last month or so when my normally cool laptop started cooking my legs. Whether the problem existed before in less-blistering form I couldn't say.

> Can small network.tcp.sendbuffer(default=131072) such as 4096, 8192 be a
> workaround for bug submitting or comment posting at bugzilla.mozilla.org?
I changed it and will let you know after posting this. Do I need to restart FF first?

	Ryan Johnson Reporter
	Comment 5 • 13 years ago

Update: I still saw 40% cpu util during the previous upload. Trying again after restarting FF.

	Ryan Johnson Reporter
	Comment 6 • 13 years ago

Update: It looks like the setting didn't stick until I restarted. With buffer size 4096 CPU util during the comment upload was no more than 20%, a significant improvement. Is there some similar setting in TB that would have an equivalent effect?

	WADA:World Anti-bad-Duping Agency
	Comment 7 • 13 years ago

(In reply to Ryan Johnson from comment #6)
> Is there some similar setting in TB that would have an equivalent effect?

Tb also uses same setting. Go Tools/Options/Advanced/General, Config Editor.

> With buffer size 4096 CPU util during the comment upload was no more than 20%,

How about network.tcp.sendbuffer=65536?
(See Bug 541367 and bugs listed in Dependency tree for that bug, with "Show Resolved", please)
As network.tcp.sendbuffer=4096 is too small usually(causes inefficient network resource use), data transmission will take longer than usual. Please find most appropriate value in your environment, please.

	Ryan Johnson Reporter
	Comment 8 • 13 years ago

(In reply to WADA from comment #7)
> (In reply to Ryan Johnson from comment #6)
> > Is there some similar setting in TB that would have an equivalent effect?
> 
> Tb also uses same setting. Go Tools/Options/Advanced/General, Config Editor.
Yes, but it's downloading, not uploading... 

> 
> > With buffer size 4096 CPU util during the comment upload was no more than 20%,
> 
> How about network.tcp.sendbuffer=65536?
> (See Bug 541367 and bugs listed in Dependency tree for that bug, with "Show
> Resolved", please)
> As network.tcp.sendbuffer=4096 is too small usually(causes inefficient
> network resource use), data transmission will take longer than usual. Please
> find most appropriate value in your environment, please.
It's really starting to sound like this is just a hack to work around the real (still unknown?) problem, which doesn't make me very enthusiastic about going further in this direction. Perhaps you could explain why tcp buffer size should impact CPU utilization so strongly?

	Ryan Johnson Reporter
	Comment 9 • 13 years ago

For comparison, I just tried loading this web page from IE9, and it has exactly *zero* cpu util during the wait, then spikes just long enough to page render the page.

	Wayne Mery (:wsmwk)
	Comment 10 • 13 years ago

(In reply to Ryan Johnson from comment #8)
> (In reply to WADA from comment #7)
> > As network.tcp.sendbuffer=4096 is too small usually(causes inefficient
> > network resource use), data transmission will take longer than usual. Please
> > find most appropriate value in your environment, please.
> It's really starting to sound like this is just a hack to work around the
> real (still unknown?) problem, which doesn't make me very enthusiastic about
> going further in this direction. Perhaps you could explain why tcp buffer
> size should impact CPU utilization so strongly?

because if the network is flakey (which includes faulty hardware) it will cause packets to be retransmitted, and thus drive up CPU

what make and model wireless router are you running?

Also, how are you determining that you have "slow/overloaded wireless connection"?

	Wayne Mery (:wsmwk)
	Comment 11 • 13 years ago

(In reply to Wayne Mery (:wsmwk) from comment #10)
> because if the network is flaky (which includes faulty hardware) it will
> cause packets to be retransmitted, and thus drive up CPU

Bug 475603 - Lots of timeouts for DNS requests with Netgear Router WGR614 - is one example of hardware problem (I don't recall whether it drove up CPU)

	Ryan Johnson Reporter
	Comment 12 • 13 years ago

(In reply to Wayne Mery (:wsmwk) from comment #10)
> (In reply to Ryan Johnson from comment #8)
> > (In reply to WADA from comment #7)
> > > As network.tcp.sendbuffer=4096 is too small usually(causes inefficient
> > > network resource use), data transmission will take longer than usual. Please
> > > find most appropriate value in your environment, please.
> > It's really starting to sound like this is just a hack to work around the
> > real (still unknown?) problem, which doesn't make me very enthusiastic about
> > going further in this direction. Perhaps you could explain why tcp buffer
> > size should impact CPU utilization so strongly?
> 
> because if the network is flakey (which includes faulty hardware) it will
> cause packets to be retransmitted, and thus drive up CPU
Somehow IE9 manages to avoid the problem (see comment 9) while using the exact same hardware, network connection, and web page (this one), which suggests that the problem lies closer to home.

> 
> what make and model wireless router are you running?
My home router is a Cisco (at work, can't remember the model), but the exact same thing happens at school and with at least two conference hotel wireless setups on different continents. Besides, the same thing occurs when there's no router at all (wireless switched off on the bus) and the connection is just plain timing out. 

> 
> Also, how are you determining that you have "slow/overloaded wireless
> connection"?
At the time of reporting, there were 300 people in the same conference session as me, all trying to read their email at the same time; one WIFI router sat on a stand in the corner. It took some tries to even get an IP address (192.168.0.0/24).

	Zhong Qiyao
	Comment 13 • 13 years ago

This also happens on slow ADSL networks.

I have the same problem with Thunderbird 8.0 sending a 4-megabyte attachment
oven an ADSL (order of 100 kb/s uplink).  It takes 20 minutes to
send, and during this 20 minutes, the computer seems hogged up.

The computer should not be hogged while simply waiting for bytes to
be sent over the network card.

Thanks.

	WADA:World Anti-bad-Duping Agency
	Comment 14 • 13 years ago

(In reply to Ryan Johnson from comment #8)
> It's really starting to sound like this is just a hack to work around the
> real (still unknown?) problem, which doesn't make me very enthusiastic about
> going further in this direction. Perhaps you could explain why tcp buffer
> size should impact CPU utilization so strongly?

No. 
It's for problem determiation.
- Even with network.tcp.sendbuffer=4096, CPU 100% still occurs,
  with SSL, SSL only problem => Bug 538283 
- With network.tcp.sendbuffer<=64KB, CPU 100% problem or connection loss
  is resolved, SSL or non-SSL is irrelevant  => Router's bug
If SSL, even when cause of CPU 100% was router's bug and resolved by network.tcp.sendbuffer<=64KB, higher CPU consumption than expected may occur due to Bug 538283. CPU utilization may be higher when network.tcp.sendbuffer=64KB than CPU utilization with network.tcp.sendbuffer=4KB if slow network. 
If Wireless network, searching appropriate network.tcp.sendbuffer value is never workaround. If probability of packet loss is high, sendbuffer size is better reduced. It's a performance tuning. 

"Do such things or not" is all up to you.

	Zhong Qiyao
	Comment 15 • 13 years ago

Responding to comment 2:
<<
When(with which build of Tb/Fx, specific date, after upgrade, ...) did your problem start to occur?
>>

using the set-up of comment 13:
<<
I have the same problem with Thunderbird 8.0 sending a 4-megabyte attachment
oven an ADSL (order of 100 kb/s uplink).
>>

It may have started far back in version 2.X or 3.X, even since I started to send large attachments, and found that my computer is hogged up, because I have not updated my Thunderbird (stayed at version 3.X) until recently.  And Thunderbird and Firefox picked up a bad habit of using up version numbers quickly.

Thanks.

	Ryan Johnson Reporter
	Comment 16 • 13 years ago

(In reply to WADA from comment #14)
> (In reply to Ryan Johnson from comment #8)
> > It's really starting to sound like this is just a hack to work around the
> > real (still unknown?) problem, which doesn't make me very enthusiastic about
> > going further in this direction. Perhaps you could explain why tcp buffer
> > size should impact CPU utilization so strongly?
> 
> No. 
> It's for problem determiation.

[snipped lots of text about knob-turning]

I'm using a very simple problem determination process here:
- Problem occurs on a wide variety of networks (home WLAN, .edu LAN, .edu WLAN, overloaded hotel WLAN ==> probably not a router config issue (they can't all be wrong)
- Problem occurs when not connected to *any* network (if TB thinks there's connectivity) ==> probably not a buffer size issue (buffer should fill "immediately" and then stop since nothing is draining it)
- Problem also occurs in FF (CPU usage while loading from a slow web site) ==> probably an issue with shared infrastructure (xul.dll?)
- Problem does *not* occur in IE ==> not an OS config problem

Maybe it is a "simple matter of tuning" but it's not a game users should have to play... for each network... for each changing situation. Especially not when other products seem able to handle the issue without user intervention. Emphatically not if it turns out the Windows profiler is right and UI redrawing overhead is [part of] the problem (see bug #686495 for details). 

> "Do such things or not" is all up to you.
"Compete or do not" is all up to you. The bar is set, and exposing this sort of knob-foolery to users is below it.

	Wayne Mery (:wsmwk)
	Comment 17 • 12 years ago

reporter, do you still see this problem when using a current version?

	Ryan Johnson Reporter
	Comment 18 • 12 years ago

(In reply to Wayne Mery (:wsmwk) from comment #17)
> reporter, do you still see this problem when using a current version?

Using 16.0.2, the problem persists. Disabling all virtual network adapters used by virtual machines on my computer helps a little (they fooled TB into thinking there was always connectivity), and doing so cuts CPU usage by almost half, but I still have to commute with TB closed to conserve battery.

Steps tried:
1. Open TB
2. Connect to internet
3. Check email
4. Disable wireless
5. Check email again
6. CPU usage jumps (split between thunderbird.exe and dwm.exe) as multiple "unable to connect" windows slide across the bottom of the screen.

	Ryan Johnson Reporter
	Comment 19 • 12 years ago

(In reply to Wayne Mery (:wsmwk) from comment #17)
> reporter, do you still see this problem when using a current version?

After updating to 17.0, the situation seems to be markedly improved. I'll try this out for a week or two to be sure, but this version may have fixed it for me.

	Ryan Johnson Reporter
	Comment 20 • 12 years ago

(In reply to Ryan Johnson from comment #19)
> (In reply to Wayne Mery (:wsmwk) from comment #17)
> > reporter, do you still see this problem when using a current version?
> 
> After updating to 17.0, the situation seems to be markedly improved. I'll
> try this out for a week or two to be sure, but this version may have fixed
> it for me.

Still no CPU hogging troubles since the upgrade. Thanks for the fix!

	Wayne Mery (:wsmwk)
	Comment 21 • 12 years ago

Thanks for the update.

	Wayne Mery (:wsmwk)
	Comment 22 • 11 years ago

FWIW this would have partly helped by changes such that every gmail message is not downloaded at least twice.

Do you find version 24 be the same or better?

	Ryan Johnson Reporter
	Comment 23 • 11 years ago

I hadn't been paying attention lately, usually I just close TB if I'm going off grid (and FF as well, if I really want to maximize battery life). 

A cursory test says it's back to the original (bad) behavior. Downloading a 27MB email from the in-laws over a decent DSL connection keeps the CPU at 30-60% during the entire download.

However, it does seem to do better at handling dropped connections: turning off the wifi while an email was downloading only spiked the CPU to 100% for about 10 seconds before it gave up (instead of 60-90 seconds like before). 

Note that I'm on a new laptop, using a new WIFI router, and all TB knobs are at defaults unless they were attached to the user profile I imported from the old machine. 

(I still don't understand why waiting on the network should use more than single-digit %CPU, *especially* if no bytes are coming down the pipe. I don't have the Windows profiler handy to see where those CPU cycles are going, though, and no time to install it right now).

	David von Oheimb
	Comment 24 • 11 years ago

I can confirm this bug for Thunderbird 24.3.0.
When using Thunderbird with a slow or intermittent cnonection or behind a firewall that requires a (SOCKS) proxy to connect to the mail server and the proxy is not properly configured, 
there is a high CPU load until the connection times out. Obviously there is some busy loop waiting for the connection.

Please remove the "TB5" part of the bug's subject.

	Javi Rueda :javirid
	Comment 25 • 10 years ago

According to comment 24

	Wayne Mery (:wsmwk)
	Comment 26 • 9 years ago

A profile will be helpful https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G
Unfortunately the symbols aren't working just now.

	Wayne Mery (:wsmwk)
	Comment 27 • 9 years ago

David, and/or Ryan?

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #26)
> A profile will be helpful
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Reporting_a_Thunderbird_Performance_Problem_with_G

	Ryan Johnson Reporter
	Comment 28 • 9 years ago

My Thunderbird experience is currently dominated by Bug #1249945, so I'm not able to tell whether this bug is still a problem.

	Wayne Mery (:wsmwk)
	Comment 29 • 9 years ago

(In reply to Ryan Johnson from comment #28)
> My Thunderbird experience is currently dominated by Bug #1249945, so I'm not
> able to tell whether this bug is still a problem.

Ryan, thanks for the update.  Please add the profile URL in your Bug #1249945 so we can view it.

	David von Oheimb
	Comment 30 • 9 years ago

Thanks Wayne for the link how to produce a profile. I still had some trouble with Cleopatra, but eventually it worked out: 
http://people.mozilla.org/~bgirard/cleopatra/?1457530381985#report=ee827feb030825119dc2230f1109b1ad88bafd0b
http://people.mozilla.org/~bgirard/cleopatra/?1457530740188#report=9e5a3847d8585a5a23c606c37ed24f43e2a36ac7
http://people.mozilla.org/~bgirard/cleopatra/?1457530381985#report=ee827feb030825119dc2230f1109b1ad88bafd0b
For current Thunderbird 38.6.0 on my Windows 7 machine, the problem persists:

When using Thunderbird with a slow or intermittent connection or the SOCKS proxy is not reachable or not properly configured, there is a high CPU load (some 30-40% on one of my CPU cores) until the connection times out. Obviously there is some busy loop waiting for the connection.

As mentioned already for several related Mozilla issues, such problems should be easily reproducible: set a non-existing proxy name and port as the SOCKS server, say: 1.2.3.4 and port 5, and then try to get/receive emails, (e.g., by clicking on an IMAP folder).

I wonder why this bug is still considered unconfirmed, since this bug is open since 2011.

	David von Oheimb
	Comment 31 • 9 years ago

Here's another profile, which may be related or not, witnessing needless high CPU load for current TB.
http://people.mozilla.org/~bgirard/cleopatra/?1457531717548#report=12f8c4d34482d37a5184eace3ad40ded9135cf69

	Wayne Mery (:wsmwk)
	Comment 32 • 8 years ago

Ryan, what AV and firewall were you running with Windows 7?  And now with windows 10?


> I wonder why this bug is still considered unconfirmed, since this bug is open since 2011.

Because of comment 10, and because we don't know the source of CPU usage and what's happening in networking. Plus the time difference between your comments in Ryan's initial bug report (plus conditions to reproduce) I'm not convinced your netowrk issue is the same as Ryan's. Only further analysis will tell. But you certainly should be good with bug 1107251 and bug 919485 

That said, 
a) there is bug 76473 (filed roughly in same time frame) and 
b) further analysis is needed, and what you and Ryan see with version 50 (beta) and newer would be most helpful (but I don't expect bad proxy to be any better)

Ryan's 3 performance bugs, with differing network conditions :
* v6, bug 686495, win7, no/disconnected network - no profiler run, but xperf shows CPU in graphics code
* bug 1249945, win10, good network, 800MB? - Ryan's profile run is 50% wait for NtWaitForMultipleObjects, ~50% CC (cycle collect), almost no painting CPU
* v6, this bug, win7, slow/bad network - no profile run from Ryan. David's v24 "proxy" profiles [1] are similar to bug 1249956 only in the high Nt waiting -  high painting CPU, ~40% wait for NtWaitForMultipleObjects, plus a high percentage of the sequence openOptionsDialog in mailcore.js, gadvancedpane.showconnections, opensubdialog

Other network performance bugs: https://mzl.la/2iXYLiS

[1] Ryan's profiles
https://cleopatra.io/#report=ee827feb030825119dc2230f1109b1ad88bafd0b
https://cleopatra.io/#report=9e5a3847d8585a5a23c606c37ed24f43e2a36ac7
https://cleopatra.io/#report=ee827feb030825119dc2230f1109b1ad88bafd0b


Note: I'm doubting bug 1249945 is calendar specific and I almost duped it, but presumably it's with a good network so keeping it open for now.

	Wayne Mery (:wsmwk)
	Comment 33 • 8 years ago

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #32)
> Ryan, what AV and firewall were you running with Windows 7?  And now with
> windows 10?
> 
> 
> > I wonder why this bug is still considered unconfirmed, since this bug is open since 2011.
> 
> Because of comment 10, and because we don't know the source of CPU usage and
> what's happening in networking. Plus the time difference between your
> comments in Ryan's initial bug report (plus conditions to reproduce) I'm not
> convinced your netowrk issue is the same as Ryan's. Only further analysis
> will tell. But you certainly should be good with bug 1107251 and bug 919485 
> 
> That said, 
> a) there is bug 76473 (filed roughly in same time frame) and 

correction, bug 764731

	David von Oheimb
	Comment 34 • 8 years ago

Thanks Wayne for answering my question regarding UNCONFIRMED.

I just noticed that in my list of profiles (given in comment 30), which you quoted in comment 32 as [1], was a duplicate, while another one (given in comment 31) was missing, so in my view the list actually is:

https://cleopatra.io/#report=ee827feb030825119dc2230f1109b1ad88bafd0b
https://cleopatra.io/#report=9e5a3847d8585a5a23c606c37ed24f43e2a36ac7
https://cleopatra.io/#report=12f8c4d34482d37a5184eace3ad40ded9135cf69

	David von Oheimb
	Comment 35 • 8 years ago

When confirming that the issues I mentioned in comment 30 still hold for TB 45.5.1, I found that the high CPU load (around 40% of one core) can not only be reproduced by setting a non-existing proxy IP address as the SOCKS host, say: 1.2.3.4, but also more directly by setting the mail server name to an unreachable IP address such as 1.2.3.4.
Then try receiving new emails, (e.g., by clicking on an IMAP folder, or using the Get All New Messages button). The load is high as long as the green wheel rotates. 

I also found that when a configured SOCKS proxy is unreachable, the timeout (after which CPU load drops again) is some 60 seconds, while the value I set for mail.server.server[n].timeout, namely 30 seconds, is not respected. 
On the other hand, when the IMAP server itself is unreachable (regardless whether TLS is enabled or not), the timeout occurs after some 125 seconds.

	David von Oheimb
	Comment 36 • 8 years ago

The different timeouts observed not only indicate that there is even more than one nasty busy loop somewhere down in the network layer, but also should be of good help spotting them. I presume that they even use hard-coded timeout values.

	Ryan Johnson Reporter
	Comment 37 • 8 years ago

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #32)
> Ryan, what AV and firewall were you running with Windows 7?  And now with
> windows 10?

My Windows 7 setup had neither installed (they broke cygwin). My Windows 10 setup had Defender for quite a while, until it started breaking my backup software a couple months ago. Now it's disabled as well. I occasionally fire up AV software to check for problems and have not found any, so I don't think that's the cause. 

In case it's relevant, my Windows 7 setup had a bog-standard Windows VPN connection that I used occasionally, and my Windows 10 setup has an OpenVPN, also used occasionally. A few months ago a Cisco VPN joined the mix, but I very rarely use it.

	David von Oheimb
	Comment 38 • 6 years ago

This bug has been reported meanwhile 7 years ago, still marked as unconfirmed, let alone fixed.
Though it has been discussed and confirmed by several people and I even spent the effort to provide profiles.

Since it is my typical - and pretty frustrating - experience with Mozilla Thunderbird that (older) bugs get neglected after a while I've just done further experiments with the latest TB version 52.9.1 and filed the still existing issue as new bug report: Bug 1488092.

	Wayne Mery (:wsmwk)
	Comment 39 • 6 years ago

(In reply to Ryan Johnson from comment #37)
> (In reply to Wayne Mery (:wsmwk, NI for questions) from comment #32)
> > Ryan, what AV and firewall were you running with Windows 7?  And now with
> > windows 10?
> 
> My Windows 7 setup had neither installed 

All imap accounts?
Does this reproduce with Windows started in safe mode? (I'm surprised I didn't ask before)
  https://support.microsoft.com/en-us/help/12376/windows-10-start-your-pc-in-safe-mode

	Wayne Mery (:wsmwk)
	Comment 40 • 6 years ago

Also, to what extent does CPU usage change if you disable (hide) start bar using View > toolbar > status bar?   (preferably with version 60)

	Ryan Johnson Reporter
	Comment 41 • 6 years ago

I just put my laptop in airplane mode and hit "Get Messages", which put CPU util at ~40% of one CPU. That might be an improvement--I think it used to be more like 80%--but it's certainly not remotely good. Then again, Thunderbird often sucks down 10-20% CPU at any given moment even when seemingly sitting idle, so yeah... CPU hog all around. Tho of course now that I'm typing this it decided to drop to 0% CPU for once. It seems to use the most CPU when any part of the window is visible (even if not in the foreground). Some of the drop vs. before might be due to me dropping down to just two accounts (instead of four).

And yes, all imap accounts. I haven't tried safe mode yet, it would be rather disruptive to my daily workflow.

I only have 52.9.1, which "Help -> about" reports as latest version for release channel?

You know, hidden status bar might actually reduce CPU util a fair bit, for both idle and bad-network scenarios. Happy to leave that off, I don't think I ever use it...

	Wayne Mery (:wsmwk)
	Comment 42 • 6 years ago

(In reply to Ryan Johnson from comment #41)
> I just put my laptop in airplane mode and hit "Get Messages", which put CPU
> util at ~40% of one CPU. That might be an improvement--I think it used to be
> more like 80%--but it's certainly not remotely good. 

That's good to hear

> Then again, Thunderbird often sucks down 10-20% CPU at any given moment even when seemingly sitting
> idle, so yeah... CPU hog all around. Tho of course now that I'm typing this
> it decided to drop to 0% CPU for once. It seems to use the most CPU when any
> part of the window is visible (even if not in the foreground). Some of the
> drop vs. before might be due to me dropping down to just two accounts (instead of four).
> 
> And yes, all imap accounts. I haven't tried safe mode yet, it would be
> rather disruptive to my daily workflow.

If the Thunderbird issue is highly reproducible, it should only take few minutes, and would help eliminate external factors that are currently unknowable.


> I only have 52.9.1,

You can download 60 from https://www.thunderbird.net/en-US/  
If you have add-ons, list them first here so we can assess whether you would be impacted.


> You know, hidden status bar might actually reduce CPU util a fair bit, for
> both idle and bad-network scenarios. Happy to leave that off,

Please quantify the difference with it on, and with it off. 
I suggest set windows' taskmanager View > Update Speed to Low, which will flatten your performance graph.

	David von Oheimb
	Comment 43 • 6 years ago

(In reply to Ryan Johnson from comment #41)
> I just put my laptop in airplane mode and hit "Get Messages", which put CPU
> util at ~40% of one CPU. That might be an improvement--I think it used to be
> more like 80%--but it's certainly not remotely good. [...] Some of the
> drop vs. before might be due to me dropping down to just two accounts
> (instead of four).

I suspect that the reduction of TB's CPU misuse by 50% in your case is not due to a bug having been fixed meanwhile but simply because you reduced the number of accounts by 50%.

> And yes, all imap accounts. I haven't tried safe mode yet, it would be
> rather disruptive to my daily workflow.
> 
> I only have 52.9.1, which "Help -> about" reports as latest version for
> release channel?
> 
> You know, hidden status bar might actually reduce CPU util a fair bit, for
> both idle and bad-network scenarios. Happy to leave that off, I don't think
> I ever use it...

As mentioned several times on Bugzilla for this and related bugs, Wayne Mery and any anyone else could easily reproduce the issue himself for doing these (and any further) tests of interest in order to narrow down the search space: Just use a non-existent IP address like 1.2.3.4 as the server address.

	David von Oheimb
	Comment 44 • 6 years ago

Why does this bug still have status UNCONFIRMED?

	David von Oheimb
	Comment 45 • 6 years ago

BTW, my workaround (when my laptop is on battery) is: 
pssuspend thunderbird

	Wayne Mery (:wsmwk)
	Comment 46 • 6 years ago

I cannot reproduce with nobody@1.2.3.4 using windows 7, thinkpad, i7, onboard wireless 6300 AGN, thunderbird 60.0b11 with status bar visible.  CPU varies between 1% and 3% for 15 seconds.

	David von Oheimb
	Comment 47 • 6 years ago

(In reply to Wayne Mery (:wsmwk) from comment #46)
> I cannot reproduce with nobody@1.2.3.4 using windows 7, thinkpad, i7,
> onboard wireless 6300 AGN, thunderbird 60.0b11 with status bar visible.  CPU
> varies between 1% and 3% for 15 seconds.

I was surprised that in your case the increase in CPU load is pretty moderate.
Still you also get an undue extra load until the connection attempt times out, though it is less prominent than in my case. 
Do you use 32- or 64-bit Thunderbird? How many cores does your i7 have?

It looks like the more cores are available, the less percentage is reported by Microsoft's task manager, 
which apparently normalizes the total load of all cores to max. 100% while on Linux the load of each core is reported up to 100%.

I've just tried again on my Win10 laptop with 4 cores, this time with a new TB profile and 32- and 64-bit TB 60.0.b11. 
Switching back to the latest current release 52.9.1 did not change anything. So the TB version and 32 vs. 64 bit makes no difference.
In all these cases I get some 3% extra load - still too much.

With my normal profile (having two accounts and storing some 4 GB of emails) the extra CPU load was higher (as I wrote, up to 10%) but currently I get less extra load: 5-6%. Interesting that the extra load is higher than with a (nearly) empty profile.

To sum up, the undue extra load varies depending on various factors. In my case it is between 12 and 40% per core.
For Wayne Mery it appears to be much less (which might be explained by having more cores and the Windows way of normalizing CPU load figures), while for Ryan Johnson it is around 40% per core.

	David von Oheimb
	Comment 48 • 6 years ago

Oops, my formulation "per core" was misleading. What I meant is: "for one core".

	David von Oheimb
	Comment 49 • 6 years ago

I just found a good potential explanation why the effect of this bug is less noticeable for Wayne Mery:
when the "Main Toolbar" is disabled, the undue extra CPU load is much less, about half compared to the situation where the rotating blue circle is not visible. Wayne, can you confirm this?

	David von Oheimb
	Comment 50 • 6 years ago

Here are two related, but certainly different bugs:

Under certain circumstances the undue extra CPU load is not terminated when the (configured) timeout passes, and when the "Main Toolbar" is visible, the blue circle keeps rotating indefinitely.

Moreover, most times the "Stop the current transfer" button has no effect (even with the latest TB 60.0.b11).

	David von Oheimb
	Comment 51 • 6 years ago

Ryan Johnson, can you confirm that the visibility of the (View -> Toolbar -> Main Toolbar makes a big difference on the undue CPU load?

	Ryan Johnson Reporter
	Comment 52 • 6 years ago

(In reply to David von Oheimb from comment #51)
> Ryan Johnson, can you confirm that the visibility of the (View -> Toolbar ->
> Main Toolbar makes a big difference on the undue CPU load?

Yes, it seems to cut it in half, give or take. I didn't turn it back on after you suggested it a few days ago.

BTW, my reported task manager CPU load is probably higher because my laptop is several years old and only has two cores.

	David von Oheimb
	Comment 53 • 6 years ago

(In reply to Ryan Johnson from comment #52)
> (In reply to David von Oheimb from comment #51)
> > can you confirm that the visibility of the (View -> Toolbar -> Main Toolbar makes a big difference on the undue CPU load?
> 
> Yes, it seems to cut it in half, give or take. I didn't turn it back on after you suggested it a few days ago.
> 
> BTW, my reported task manager CPU load is probably higher because my laptop is several years old and only has two cores.

Thanks Ryan - this confirms my conjectures that 
* the CPU usage figures reported on a Windows system needs to be multiplied by the number of cores in order to determine the actual load (for the core assigned to Thunderbird) and that
* 50% of the undue CPU load are caused by rendering the rotating blue circle. 

As mentioned, the extra CPU load can be quite a waste of battery capacity in case of frequent connection attempts and/or long connection timeouts (or in case the timeout is ignored under some circumstances, which must be due to the related bug I mentioned above).

	Wayne Mery (:wsmwk)
	Comment 54 • 6 years ago

(Qiyao is no longer with us)

Please try the following.  Put

.progressmeter-statusbar {
  display: none !important;
}
.tab-throbber {
  display: none !important;
}

into <profile>\chrome\userChrome.css   If the folder and/or file does not exist, create it.

How does this affect your cpu usage?

	David von Oheimb
	Comment 55 • 6 years ago
workaround

Thanks Wayne for this very helpful hint!

Disabling display of these two items via CSS did not yet remove (all) the extra CPU load,
but in conjunction with removing the Activity Indicator (the rotating light blue circle) from the Mail Toolbar (right-clicking on it -> Customize -> dragging the icon down into the window that just opened) it does :)

In fact, this combination of workarounds makes Thunderbird usable again on my laptop. Since I did not anymore have the hope that the various TB bugs I had reported or contributed to their discussion ever get taken serious and fixed I was already considering giving up on Thunderbird (at least on my laptop) and had already started using eM Client.

	David von Oheimb
	Comment 57 • 6 years ago

Could you please mark this bug as confirmed.

	Wayne Mery (:wsmwk)
	Comment 58 • 6 years ago

Ryan, 
To what extent does comment 54 change your CPU usage for this bug and bug 1249945?

	David von Oheimb
	Comment 59 • 6 years ago

@Ryan, maybe you overlooked the new question to you of Sep 9th?

	Ryan Johnson Reporter
	Comment 60 • 6 years ago • Edited

(In reply to Wayne Mery (:wsmwk) from comment #58)
> Ryan, 
> To what extent does comment 54 change your CPU usage for this bug and bug 1249945?

(In reply to David von Oheimb from comment #59)
> @Ryan, maybe you overlooked the new question to you of Sep 9th?

Sorry, I did miss this. Getting rid of the main toolbar made CPU usage much more manageable, and then Teh Busy hit.

I just tried out the css fix as well, not sure the CPU situation changed much. Basically, any time TB is in the foreground, it takes 50-100% of a CPU... but at least now its CPU usage drops to ~0% after a few seconds when it's not in the foreground.

I still close TB when on an airplane that lacks in-seat power (no internet anyway), but it's definitely nowhere near as bad as it used to be.

	David von Oheimb
	Comment 61 • 6 years ago

I just did one more experiments with the TB installation on my Linux box where my profile contains 10 email accounts.

After hitting the "Get All New Messages" button, the CPU load briefly spiked to 100% and then was stuck at 30% (of one core).
After choosing "Work Offline", the load went down to some 3%. When re-enabling online state, CPU load stayed low.

After hitting the "Get All New Messages" button again, there was high CPU load just for a few seconds before returning to low.

	David von Oheimb
	Comment 62 • 6 years ago
important

Here is one more experiment clearly indicating that in fact the DOM element with Id #statusbar-icon of class .progressmeter-statusbar (full path: window#messengerWindow statusbar#status-bar.chromeclass-status hbox#statusTextBox statusbarpanel#statusbar-progresspanel.statusbarpanel-progress progressmeter#statusbar-icon.progressmeter-statusbar)
and not an element of class .tab-throbber has a pretty bad effect on CPU load:

1. Set the "Connection security" settings of a Gmail account to "STARTTLS" (rather than the correct value "SSL/TLS").
2. Try getting emails from this account.
3. Until the connection times out, the status bar moves forth and back and CPU load is some 30% (of one core).

4. Add to <profile>/chrome/userChrome.css (similarly to what Wayne suggested above):
   #statusbar-icon {
      display: none;
   }
   or do this modification via the Developer Toolbox.
5. Try getting emails from this account again.
6. No moving status bar appears and CPU load remains low.

	David von Oheimb
	Comment 63 • 6 years ago

Again, why is this bug still marked UNCONFIRMED?!?