goomail59@gmail.com wrote:
> All,
>
> I am wondering if anyone is seeing moderate amounts of CPU usage with
> Thunderbird 2.0.0.17 when it is idle. ("Moderate" is relative, because
> we are talking about the idle case.) For reference purposes, I am
> running OS X 10.5.5 on the latest 2.4 GHz MacBook Pro.
>
> When the app starts up, CPU usage is hovering in the 0.0-0.3% range,
> which is certainly acceptable. At some point, however, the CPU usage
> kicks up to 5-8% and remains that way until I shut down and restart
> Thunderbird. I have not yet been able to correlate the uptick in CPU
> usage with any specific action.
>
> I know that this still leaves a reasonable amount of CPU for other
> apps, but it seems wrong--it's just an email client, after all. Unless
> I'm missing something (am I?), the app should be waiting for UI events
> and all of its threads should be blocked on semaphores (except for the
> occasional polling of mail servers). I'm simply not sure of what it is
> doing with 120-190 MHz of processing power.
>
> Does anyone have any tips to share? The only add-ons I have installed
> are the Header Scroll Extension and the Growl Notifier.
>
> Scott
>



I fired up Activity Monitor, and when Thunderbird is at idle, it really
is at idle. Shows 0.00 % of CPU being used. I get activity when I am
writing this email, anywhere from 0 to 9%, but if I pause for a few
seconds, the activity goes back to 0.00.

What time frame do you have Growl checking on?
What time frame do you have Thunderbird set to check for new mail?
and newsgroups as well?

I would suggest you run once in 'safe' mode, and monitor the CPU usage
during the run. This would either clear the extensions of involvement or
identify them as contributors

Safe mode in Mac OSX
On Mac OS X, go to Utilities (in the Applications folder) and open
Terminal, then run (for Firefox):

* /Applications/Firefox.app/Contents/MacOS/firefox -safe-mode

And for Thunderbird, this is the line to run in Terminal:

* /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin
-safe-mode

If you have installed the application to another location, modify the
path as such. It's the "-safe-mode" command line parameter that's
crucial here.

Let me know the results

Dan,

Thanks for your response. This email is a bit of train-of-thought, for
which I apologize. I appear to have identified the issue that causes
the CPU problem, but I'm not sure of how to fix it:

> > When the app starts up, CPU usage is hovering in the 0.0-0.3% range,
> > which is certainly acceptable. At some point, however, the CPU usage
> > kicks up to 5-8% and remains that way until I shut down and restart
> > Thunderbird. I have not yet been able to correlate the uptick in CPU
> > usage with any specific action.
>
> What time frame do you have Growl checking on?
> What time frame do you have Thunderbird set to check for new mail?
> and newsgroups as well?
>
> I would suggest you run once in 'safe' mode, and monitor the CPU usage
> during the run. This would either clear the extensions of involvement or
> identify them as contributors.

I tried running in safe mode (actually, I disabled all of the
extensions and then shut down to run in safe mode), but I'm still
seeing the same symptoms. Presumably this means that my Growl
notification period is unrelated.

One of my accounts is checking for new mail every 2 minutes; two other
accounts check every 10; and the remaining accounts are not set up to
poll for mail automatically at all.

OK, here is something interesting. I am toying around with the 'Sample
Process' feature in Activity Monitor, and I ran a couple of samples of
TB when it got into the fixed state. Most of the process threads look
like they are doing something relatively benign and not CPU-hogging
(like sitting on semaphores), but I saw a couple that looked weird:

1- The XRE_main thread is occasionally running
'__CFRunLoopDoObservers' (1 out of 351 samples)
2- The CAPThread thread is mostly waiting for a semaphore, but it's
sometimes doing some weird I/O. It looks like it's doing something
with audio? It had a ginormous call tree that starts with
HP_IOThread:PerformIO and ends up calling a whole bunch of crap
(AudioConverterFillComplexBuffer, CRBConverter::RenderOutput,
AUMatrixMixerEntry, AudioCOntextProcessor::Render, RenderInputProc, ad
infinitum) (9 out of 351 samples)

I ran the sampler a second time and got slightly different results
(XRE_main was doing something else), but the CAPThread was still
getting sampled doing similar things.

I then restarted TB and did a sample while in a "known good" state,
but I didn't see any more of the crazy audio thread in that sample
set. The 9/351 sampling frequency would point to the CAPThread being a
possible culprit. (Is that the special thread where the NSA records my
mic input?)

I would also be happy to take off my tinfoil hat, fire up Instruments
and poke around in more detail, if only I knew what to look for.

All right...I thought about it some more, and the next "well, duh"
step is to see if this is audio-related. Sure enough, if I start TB
and check for mail, CPU usage remains at 0% so long as I have no new
mail.

I can now reliably repro the problem by _receiving new mail_. As soon
as a new message comes in, I get my usual "bling" noise and then CPU
shoots up (and stays up until I quit TB).

I was also able to confirm that, by turning off the "Play a sound when
new message arrives" feature and restarting, CPU returns to zero after
receiving new mail, so it's directly related to the sound feature and
not related to receiving email.

For that matter, simply going into Prefs->General and then clicking on
the "Play" button next to the sound is enough to reproduce the issue
and peg the CPU high.

So, I've apparently isolated the problem and I know how to work around
it...but I'd really like to hear sounds when email is received. Any
further thoughts? Can anyone else reproduce this?

Thanks for the help that you (or anyone else) can provide!

Scott

goomail59@gmail.com wrote:
> Dan,
>
> Thanks for your response. This email is a bit of train-of-thought, for
> which I apologize. I appear to have identified the issue that causes
> the CPU problem, but I'm not sure of how to fix it:
>
>>> When the app starts up, CPU usage is hovering in the 0.0-0.3% range,
>>> which is certainly acceptable. At some point, however, the CPU usage
>>> kicks up to 5-8% and remains that way until I shut down and restart
>>> Thunderbird. I have not yet been able to correlate the uptick in CPU
>>> usage with any specific action.
>> What time frame do you have Growl checking on?
>> What time frame do you have Thunderbird set to check for new mail?
>> and newsgroups as well?
>>
>> I would suggest you run once in 'safe' mode, and monitor the CPU usage
>> during the run. This would either clear the extensions of involvement or
>> identify them as contributors.
>
> I tried running in safe mode (actually, I disabled all of the
> extensions and then shut down to run in safe mode), but I'm still
> seeing the same symptoms. Presumably this means that my Growl
> notification period is unrelated.
>
> One of my accounts is checking for new mail every 2 minutes; two other
> accounts check every 10; and the remaining accounts are not set up to
> poll for mail automatically at all.
>
> OK, here is something interesting. I am toying around with the 'Sample
> Process' feature in Activity Monitor, and I ran a couple of samples of
> TB when it got into the fixed state. Most of the process threads look
> like they are doing something relatively benign and not CPU-hogging
> (like sitting on semaphores), but I saw a couple that looked weird:
>
> 1- The XRE_main thread is occasionally running
> '__CFRunLoopDoObservers' (1 out of 351 samples)
> 2- The CAPThread thread is mostly waiting for a semaphore, but it's
> sometimes doing some weird I/O. It looks like it's doing something
> with audio? It had a ginormous call tree that starts with
> HP_IOThread:PerformIO and ends up calling a whole bunch of crap
> (AudioConverterFillComplexBuffer, CRBConverter::RenderOutput,
> AUMatrixMixerEntry, AudioCOntextProcessor::Render, RenderInputProc, ad
> infinitum) (9 out of 351 samples)
>
> I ran the sampler a second time and got slightly different results
> (XRE_main was doing something else), but the CAPThread was still
> getting sampled doing similar things.
>
> I then restarted TB and did a sample while in a "known good" state,
> but I didn't see any more of the crazy audio thread in that sample
> set. The 9/351 sampling frequency would point to the CAPThread being a
> possible culprit. (Is that the special thread where the NSA records my
> mic input?)
>
> I would also be happy to take off my tinfoil hat, fire up Instruments
> and poke around in more detail, if only I knew what to look for.
>
> All right...I thought about it some more, and the next "well, duh"
> step is to see if this is audio-related. Sure enough, if I start TB
> and check for mail, CPU usage remains at 0% so long as I have no new
> mail.
>
> I can now reliably repro the problem by _receiving new mail_. As soon
> as a new message comes in, I get my usual "bling" noise and then CPU
> shoots up (and stays up until I quit TB).
>
> I was also able to confirm that, by turning off the "Play a sound when
> new message arrives" feature and restarting, CPU returns to zero after
> receiving new mail, so it's directly related to the sound feature and
> not related to receiving email.
>
> For that matter, simply going into Prefs->General and then clicking on
> the "Play" button next to the sound is enough to reproduce the issue
> and peg the CPU high.
>
> So, I've apparently isolated the problem and I know how to work around
> it...but I'd really like to hear sounds when email is received. Any
> further thoughts? Can anyone else reproduce this?
>
> Thanks for the help that you (or anyone else) can provide!
>
> Scott
>


Problem confirmed
Setting a sound other than a system alert causes CPU usage to remain at
a heightened state, even when Thunderbird is idle. Preliminary findings
indicate that the 'amount' of CPU usage is tied to the size of the .wav
file used as the sound (very small sampling data - unconfirmed at this
point)

Workaround:
[Thunderbird-->Preferences]*-->General
[X] Play System Sound

And doing a restart of Thunderbird should remove the heightened CPU usage.

I am submitting this as a bug, will advise.
https://bugzilla.mozilla.org/show_bug.cgi?id=459183

you can add your comments there if you wish.

Moz Champion (Dan) wrote:
> goomail59@gmail.com wrote:
>> Dan,
>>
>> Thanks for your response. This email is a bit of train-of-thought, for
>> which I apologize. I appear to have identified the issue that causes
>> the CPU problem, but I'm not sure of how to fix it:
>>
>>>> When the app starts up, CPU usage is hovering in the 0.0-0.3% range,
>>>> which is certainly acceptable. At some point, however, the CPU usage
>>>> kicks up to 5-8% and remains that way until I shut down and restart
>>>> Thunderbird. I have not yet been able to correlate the uptick in CPU
>>>> usage with any specific action.
>>> What time frame do you have Growl checking on?
>>> What time frame do you have Thunderbird set to check for new mail?
>>> and newsgroups as well?
>>>
>>> I would suggest you run once in 'safe' mode, and monitor the CPU usage
>>> during the run. This would either clear the extensions of involvement or
>>> identify them as contributors.
>>
>> I tried running in safe mode (actually, I disabled all of the
>> extensions and then shut down to run in safe mode), but I'm still
>> seeing the same symptoms. Presumably this means that my Growl
>> notification period is unrelated.
>>
>> One of my accounts is checking for new mail every 2 minutes; two other
>> accounts check every 10; and the remaining accounts are not set up to
>> poll for mail automatically at all.
>>
>> OK, here is something interesting. I am toying around with the 'Sample
>> Process' feature in Activity Monitor, and I ran a couple of samples of
>> TB when it got into the fixed state. Most of the process threads look
>> like they are doing something relatively benign and not CPU-hogging
>> (like sitting on semaphores), but I saw a couple that looked weird:
>>
>> 1- The XRE_main thread is occasionally running
>> '__CFRunLoopDoObservers' (1 out of 351 samples)
>> 2- The CAPThread thread is mostly waiting for a semaphore, but it's
>> sometimes doing some weird I/O. It looks like it's doing something
>> with audio? It had a ginormous call tree that starts with
>> HP_IOThread:PerformIO and ends up calling a whole bunch of crap
>> (AudioConverterFillComplexBuffer, CRBConverter::RenderOutput,
>> AUMatrixMixerEntry, AudioCOntextProcessor::Render, RenderInputProc, ad
>> infinitum) (9 out of 351 samples)
>>
>> I ran the sampler a second time and got slightly different results
>> (XRE_main was doing something else), but the CAPThread was still
>> getting sampled doing similar things.
>>
>> I then restarted TB and did a sample while in a "known good" state,
>> but I didn't see any more of the crazy audio thread in that sample
>> set. The 9/351 sampling frequency would point to the CAPThread being a
>> possible culprit. (Is that the special thread where the NSA records my
>> mic input?)
>>
>> I would also be happy to take off my tinfoil hat, fire up Instruments
>> and poke around in more detail, if only I knew what to look for.
>>
>> All right...I thought about it some more, and the next "well, duh"
>> step is to see if this is audio-related. Sure enough, if I start TB
>> and check for mail, CPU usage remains at 0% so long as I have no new
>> mail.
>>
>> I can now reliably repro the problem by _receiving new mail_. As soon
>> as a new message comes in, I get my usual "bling" noise and then CPU
>> shoots up (and stays up until I quit TB).
>>
>> I was also able to confirm that, by turning off the "Play a sound when
>> new message arrives" feature and restarting, CPU returns to zero after
>> receiving new mail, so it's directly related to the sound feature and
>> not related to receiving email.
>>
>> For that matter, simply going into Prefs->General and then clicking on
>> the "Play" button next to the sound is enough to reproduce the issue
>> and peg the CPU high.
>>
>> So, I've apparently isolated the problem and I know how to work around
>> it...but I'd really like to hear sounds when email is received. Any
>> further thoughts? Can anyone else reproduce this?
>>
>> Thanks for the help that you (or anyone else) can provide!
>>
>> Scott
>>
>
>
> Problem confirmed
> Setting a sound other than a system alert causes CPU usage to remain at
> a heightened state, even when Thunderbird is idle. Preliminary findings
> indicate that the 'amount' of CPU usage is tied to the size of the .wav
> file used as the sound (very small sampling data - unconfirmed at this
> point)
>
> Workaround:
> [Thunderbird-->Preferences]*-->General
> [X] Play System Sound
>
> And doing a restart of Thunderbird should remove the heightened CPU usage.
>
> I am submitting this as a bug, will advise.
> https://bugzilla.mozilla.org/show_bug.cgi?id=459183
>
> you can add your comments there if you wish.


It would seem that this bug will be fixed in Thunderbird 3, there is
currently another bug that is camoflauging the issue perhaps, but the
fix for that has been submitted. The next build should reveal whether or
not this bug still exists. Will advise

> >> I can now reliably repro the problem by _receiving new mail_. As soon
> >> as a new message comes in, I get my usual "bling" noise and thenCPU
> >> shoots up (and stays up until I quit TB).
>
> > Setting a sound other than a system alert causesCPUusage to remain at
> > a heightened state, even when Thunderbird isidle. Preliminary findings
> > indicate that the 'amount' ofCPUusage is tied to the size of the .wav
> > file used as the sound (very small sampling data - unconfirmed at this
> > point)
>
> > Workaround:
> > [Thunderbird-->Preferences]*-->General
> > [X] Play System Sound
>
> > I am submitting this as a bug, will advise.
> >https://bugzilla.mozilla.org/show_bug.cgi?id=459183
>
> > you can add your comments there if you wish.
>
> It would seem that this bug will be fixed in Thunderbird 3, there is
> currently another bug that is camoflauging the issue perhaps, but the
> fix for that has been submitted. The next build should reveal whether or
> not this bug still exists. Will advise

Just for the reference of anyone else who may be looking at this
issue:

Dan's above workaround for using the "System Sound" works to eliminate
the CPU usage, but it's not particularly user-friendly (since you no
longer get a distinguishable tone for mail). I just discovered a
better workaround: assuming that you have Growl installed, the best
solution is to turn off *all* audio alerts in Thunderbird, and then
use the per-application preferences in Growl to play the noise that
you want upon receiving a new-message Growl.

The only real downside to this solution is that it will play one tone
per email received--but this isn't as bad as it seems, since it will
play the tones concurrently if it receives a whole bunch of email at
once. The alert noise may seem a little weird if you get a big batch
of mail, but I haven't had any problems at all since enabling this
method a week ago.

Thanks again to Dan for confirming the problem!