[upstream] Very high CPU and slow responsiveness in Thunderbird 91-102
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Thunderbird |
Confirmed
|
Unknown
|
|||
thunderbird (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
Very high CPU and slow responsiveness in Thunderbird 91.5.0 and later. Just moving the mouse cursor over a message list results in 365% CPU for me.
I had to set this in the config editor to fix it:
gfx.webrender
Upstream bug: https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#2 |
this stupid system does not allow me to adjust what i have just posted (possibly admin or creators wants to waste the time of the developers)
unified Inbox -> TB/View/
but the issue happen also in normal folders.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#3 |
Please create a profile using https:/
Thanks
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#4 |
I am not willing to publish it here for privacy reason. If anyone is able to fix the issue and is unable to reproduce it, then let me know the private contact and i will try to provide the detail.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#5 |
(In reply to 794632548 from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
>
> Steps to reproduce:
>
> My Linux Arch/Manjaro TB package was just upgraded:
> 78.14.0-0.1 -> 91.1.0-0.1
> and immediately i have noticed the new feature/issue:
> in the unified Inbox i am moving mouse up/down quickly through the list of e-mails and i can see that the line the mouse is on is highlighted with delay, meaning that this highlight action may be not optimized/badly made or CPU heavy.
> And i think that my XFCE tray CPU usage meter is showing that the CPU usage rise when i move the mouse through the list of e-mails.
arnauld, can you reproduce this?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#6 |
(In reply to Wayne Mery (:wsmwk) from comment #4)
> arnauld, can you reproduce this?
Hello,
Laptop hp OS: Manjaro 21.1.2 Pahvo / Kernel: x86_64 Linux 4.19.205-1-MANJARO
CPU: Intel Core i3 M 330 @ 4x 2.133GHz GPU: NVA8 RAM: 2396MiB / 3870MiB
TB: 91.1.0 (64-bit)
> in the unified Inbox i am moving mouse up/down quickly through the list of e-mails and i can see that the line the mouse is on is > highlighted with delay, meaning that this highlight action may be not optimized/badly made or CPU heavy.
For me I have no problems, I move the mouse up/down/highlighted quickly with no delay at all.
> And i think that my XFCE tray CPU usage meter is showing that the CPU usage rise when i move the mouse through the list of e-mails.
When I move the mouse quickly through the list of e-mails my TB CPU usage is between 1 to 30%.
So everything is working fine for me, no problems at all.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#7 |
I wanted to post a proof video what i am doing and the issue i am seeing, [here please](https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#8 |
Related concerns found in [Archlinux forum](https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#9 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#10 |
ya I'm seeing this also. Thunderbird hangs for a few seconds when selecting an email and scrolling down the body. It happens initially then seems to be ok. It's almost reproducible... just click on another email, click back to the original, and try scrolling down. Do this until it occurs again. This also triggers an error:
IPDL protocol error: Handler returned error code!
###!!! [Parent]
Other errors include:
ERROR style::
(xfce4-panel:659): xfce4-panel-
JavaScript error: resource:
The later actually causes my display to go black for a few seconds!!! Could be unrelated, but only happens when launching thunderbird. Effects v91.1.0 and up.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#11 |
This one also:
JavaScript error: resource:
This is on Arch (XFCE).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#12 |
I have the same problem and I'm running Thunderbird on Windows 7 x64. Previous major version (78.X) worked without a problem.
When moving the mouse cursor over the emails in the message list pane, the highlight effect considerably lags behind the cursor (similar to the video posted by the reporter). Checking the Task Manager shows two Thunderbird processes jump to a combined CPU usage of 60-80 % (the first process takes 50-70 % and the second between 10-20 %).
Computer: CPU: Intel Q6600 @ 2.4 GHz / 8 GB RAM / GPU: Radeon HD 5850 1 GB VRAM / Windows 7 x64
TB: 91.1.1 (32-bit)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#13 |
Changing severity to S3 because of modest performance
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#14 |
I see at least two reports confirming this in Mozilla Thunderbird support, including Windows, Mac and GNU/Linux - and I have the same problem (TB 91.1.2 on Windows 10).
This makes Thunderbird slow to the point it can't be used normally.
A possible workaround was mentioned here :
https:/
> If I go to preferences --> config editor and search for the entries:
>
> gfx.webrender.all
> gfx.webrender.
>
> Switch the first one to false (it was already switched to false) and the second one to true (I switched this one manually)
> everything works smooths and no cpu usage jumps happen.
I suggest raising importance/
A few references to people reporting this problem :
* https:/
* https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#16 |
The workaround worked for me (GNU/Linux).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#17 |
Same problem Thunderbird 91.1.2 on macOS 11.6, i7, 32GB.
Just moving the mouse over folder entries, without clicking, was so slow it was unusable.
Workaround worked for me as well.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#18 |
I was the author of the previously mentioned thread in the ArchLinux forum (comment [#7](https:/
Just dropping by to confirm: The workaround quoted in comment [#13](https:/
After changing the two values, Thunderbird's idle CPU usage drops below 1 % according to htop and sits (close) to 0 % frequently. When hovering over e-mails or folders, no significant increase of CPU load can be observed.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#19 |
On my 4.2GHz i7 running Fedora 34 I regularly (20-30 times in an 8-hour day) have the UI freeze until GNOME's "application not responding, wait or kill" message appears. I'd respectfully suggest S3 is much too low.
thunderbird/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#20 |
The workaround seems to 'fix' Thunderbird 91.1.0 Fedora 34 (thunderbird-
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#21 |
Confirming based on multiple reports. But the resolution likely must come from the removal of xul in bug 1724841 (which won't happen until next year), or in combination of a graphic fix by firefox core developers (based on a performance profile, as mentioned in bug 1697999).
Does anyone have a workaround that has webrender enabled but some sub functionality disabled?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#22 |
Reporting on additional unwanted behavior which doesn't get resolved using the workaround mentioned in comment [#13](https:/
The same high lag and slowness is noticed when scrolling through the e-mail/message list pane, either using the mouse scroll wheel or the scroll bar.
Running on Windows 7 x64, TB version: 91.2.0(32-bit).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#23 |
(In reply to cdcwvbjibv from comment #21)
> Reporting on additional unwanted behavior which doesn't get resolved using the workaround mentioned in comment [#13](https:/
>
> The same high lag and slowness is noticed when scrolling through the e-mail/message list pane, either using the mouse scroll wheel or the scroll bar.
>
> Running on Windows 7 x64, TB version: 91.2.0(32-bit).
Correction.
Running on Windows 7 x64, TB version: 91.2.0 (64-bit).
description: | updated |
Changed in thunderbird (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Triaged |
summary: |
- Very high CPU and slow responsiveness in Thunderbird 91.5.0 + [upstream] Very high CPU and slow responsiveness in Thunderbird 91.5.0 |
tags: | added: upstream |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#24 |
Downstream Ubuntu bug: https:/
description: | updated |
Changed in thunderbird: | |
status: | Unknown → Confirmed |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#25 |
I confirm this on the most recent distributions of Arch Linux and Thunderbird.
The suggested fix works to solve the sluggishness.
summary: |
- [upstream] Very high CPU and slow responsiveness in Thunderbird 91.5.0 + [upstream] Very high CPU and slow responsiveness in Thunderbird 91 |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#26 |
Running on Fedora-35, with KDE, Radeon RX6600, and Thunderbird 91.7.0, I can confirm that the above suggested fix does *NOT* solve the high-cpu usage problem. Even after setting "gfx.webrender.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
RAJDEEP RAJESH THAKARE (rajdeep-thakare) wrote : Re: [upstream] Very high CPU and slow responsiveness in Thunderbird 91 | #27 |
I have
Ubuntu 22.04 LTS,
8GB RAM,
i5 4-Core Intel CPU,
SSD,
It's a Laptop.
I am facing same issue, I have installed Thunderbird 91.8.0 (64-bit), and the CPU usage is high and the interface is not responsive, the cursor lags, feels heavy while using.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | #28 |
I'm having similar problems again in 1:91.9.
But the fix for the original problem is still active:
gfx.webrender.all = false
gfx.webrender
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | #29 |
If I revert the above settings then the problem gets even worse. So it seems we might have multiple different 100% CPU bugs now.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
UlfZibis (ulf-zibis) wrote (last edit ): | #30 |
I'm having similar problems in 1:91.10.
See also: https:/
A workaround for me is:
gfx.webrender
Because of this bug: https:/
I have installed this PPA: https:/
Maybe, this is the source for the current problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
UlfZibis (ulf-zibis) wrote : | #31 |
From another side I got the hint, that miss-configured (web)rendering could be the source of the problem and cause lots of time spent in error logging. See:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
UlfZibis (ulf-zibis) wrote : | #32 |
I now discovered, that webrender is disabled by default in Firefox 101 on Ubuntu. So the question is, why it is enabled by default in Thunderbird.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#33 |
Same here on Fedora 36, Thunderbird 91.8.0 (64 bit).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#34 |
More interesting, is can anyone reproduce this when using version 102? from https:/
Webrender is much improved in version 102 for Windows. Perhaps it is also better for Linux.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#35 |
I can reproduce this on Fedora 36 with Thunderbird 102.2.0 on Wayland.
Setting `gfx.webrender.all false` and `gfx.webrender.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#36 |
A capture documenting this bug with Thunderbird 102.2 on Linux (Fedora 36, Wayland): <https:/
Between 1.5s and 4.5s the mouse pointer is moving over the message list.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#37 |
Debian 11 just upgraded to Thunderbird 102, which has removed the possibility of disabling webrender, rendering Thunderbird on my computer basically unusable. I was forced to downgrade to version 91.
high CPU usage and around 100ms delay on hover animations when moving mouse over emails and menu items.
System is Debian 11.5, Xfce, AMD Ryzen 4750u with integrated graphics in a Thinkpad T14 AMD Gen 1.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
> which has removed the possibility of disabling webrender
I assume you already tried the newest graphics drivers.
Why would you want to *completely * disable WebRender? Do hardware AND software WebRender crash for you? You can set gfx.webrender.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#39 |
(In reply to Sören Hentzschel from comment #31)
> > which has removed the possibility of disabling webrender
>
> I assume you already tried the newest graphics drivers.
>
> Why would you want to *completely * disable WebRender? Do hardware AND software WebRender crash for you? You can set gfx.webrender.
Perhaps it's not actually realted to webrender, I just assumed that because disabling it solved problems in the past. I use the drivers built into the kernel and I am on a 5.18 kernel. There were no differences in performance with software mode, so it could very well not be related to webrender.
It seems that the high CPU usage and slow UI update is worse when the message list is big and the window is big. If I make it that only 10 rows are visible, it seems to be faster. Here is a profile of the mouse moving around a large message list. https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#40 |
I am seeing the exactly same behavior as Adi on Ubuntu 22.04. I manually upgraded to Thunderbird 102 via the mozilla ppa and I am seeing the same high CPU usage on mouse hover and delayed animations, which made the UI almost unusable for me. My first guess was also the WebRender as I had to disable it for Thunderbird 91. However, I do use Firefox 105 without problems. So maybe it is indeed a different issue.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
(In reply to Adi from comment #32)
> ...
> It seems that the high CPU usage and slow UI update is worse when the message list is big and the window is big. If I make it that only 10 rows are visible, it seems to be faster. Here is a profile of the mouse moving around a large message list. https:/
According to experts in matrix chat, "https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Thibaut Vandervelden (thvdveld) wrote : Re: [upstream] Very high CPU and slow responsiveness in Thunderbird 91 | #41 |
I am also seeing the same behaviour. Previously I just disabled the WebRender as well (since that made the difference in being not laggy), just to make Thunderbird useable. Here is my profile when moving the mouse over the messages: https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#43 |
> It seems that the high CPU usage and slow UI update is worse when the message list is big and the window is big. If I make it that only 10 rows are visible, it seems to be faster. Here is a profile of the mouse moving around a large message list.
I can confirm exactly this! Working on a 2 screen setup:
main screen: 3840x2160
secondary: 2560x1440
Arch Linux, Swaywm. Usually all clients (windows) are maximized.
Thunderbird on the main screen has a very bad performance. It is everything else than fun to work with.. :(
As soon as i move thunderbird to the second screen (or switch to floating an make it smaller) the performance increases significantly.
It seems like only the email list is affected. Folder tree for example is fine..
It's been a long time now and kinda renders thunderbird more or less unusable for me. Is there anything I can do to get this fixed? Happy to provide more information if needed!
Thanks for effort :)
summary: |
- [upstream] Very high CPU and slow responsiveness in Thunderbird 91 + [upstream] Very high CPU and slow responsiveness in Thunderbird 91-102 |
description: | updated |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
> Perhaps it's not actually realted to webrender, I just assumed that because disabling it solved problems in the past.
+1. Webrender on/off does not matter here at all.
Maybe also worth mentioning:
I am on a 10th gen Intel GPU with 6.0.9-zen1-1-zen kernel
Boring workaround:
Switch to classic view and move the reading pane up until the message list is snappy enough
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#45 |
Good development progress is being made on "deforestation". Beta should be available on a month or two. And then released in July with version 115.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
Thanks for the update. I just tried Thunderbird 111 beta 2 "Supernova" on Ubuntu 22.04 but unfortunately the situation (laggy UI, very high CPU usage on moving mouse cursor in message pane) is still the same. Let's hope the next version will improve on that.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#47 |
I tried the latest Thunderbird 112 beta 6 and unfortunately the situation is still the same. I also managed to capture a profile of simply moving the mouse cursor vertically across the message pane window. My CPU usage goes up to 25% (on a 4-core CPU) while doing so: https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
I am having the same issue with ~25% CPU usage when hovering over the messages list and from what I can observer this is somehow related to the HiDPI monitor I am using (27' LG, 4k)?
OS: Fedora 37
TB: 102.9.1
Nvidia 3060Ti + X11 (Also tested this with an AMD RX 580 and X11 and Wayland - same issue)
Ryzen 5 3400G (4 cores/8 threads)
16G Memory
Also recorded a profile: https:/
I have another Fedora 37 system at work (i7-8700 w/ onboard graphics) and a 1440p monitor and here I have no issues at all. I hope this can be fixed in the not so far future - TB is really laggy at this point for me :-/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
mgw (michaelweigelt) wrote : | #49 |
OS: 5.15.0-52-generic #58~20.04.1-Ubuntu
TB: 102.10.0
Nvidia Quadro 1000M
Intel Core i7-2760QM
16 GB RAM
Same issue here plus time outs w/ 100% CPU utilization for approx. 20 sec.
I noticed that the above mentioned paramter is gone (gfx...
All this happend after latest upgrade to 102 w/ no changes in configuration.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#50 |
(In reply to Fabian Rodriguez:MagicFab from comment #13)
> I see at least two reports confirming this in Mozilla Thunderbird support, including Windows, Mac and GNU/Linux - and I have the same problem (TB 91.1.2 on Windows 10).
>
> This makes Thunderbird slow to the point it can't be used normally.
>
> A possible workaround was mentioned here :
> https:/
>
> > If I go to preferences --> config editor and search for the entries:
> >
> > gfx.webrender.all
> > gfx.webrender.
> >
> > Switch the first one to false (it was already switched to false) and the second one to true (I switched this one manually)
> > everything works smooths and no cpu usage jumps happen.
>
> I suggest raising importance/
>
> A few references to people reporting this problem :
>
> * https:/
> * https:/
The mentioned parameter (gfx...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#51 |
(In reply to Sebastian from comment #40)
> I am having the same issue with ~25% CPU usage when hovering over the messages list and from what I can observer this is somehow related to the HiDPI monitor I am using (27' LG, 4k)?
>
> OS: Fedora 37
> TB: 102.9.1
> Nvidia 3060Ti + X11 (Also tested this with an AMD RX 580 and X11 and Wayland - same issue)
> Ryzen 5 3400G (4 cores/8 threads)
> 16G Memory
>
> Also recorded a profile: https:/
nsTreeBodyFrame
nsTreeBodyFrame
nsMsgDBView:
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#52 |
Still no improvement with latest beta (114b3). I really wonder if this will ever get addressed. For me, it's a definite blocker and I am still using 91.8 for that reason. But I don't think I can stay much longer on such an old version. Will probably have to look for another mail client after 20 years of using TB...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#53 |
Did anybody try to start with a clean profile restoring previous and reproduce the error?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#54 |
Tested with a clean profile and thew new 115b1. Problem is still the same ("feels" even slightly worse, although I don't have hard measurements on that).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#55 |
Version 102.12.0 seems to have fixed the issue on my setup (Debian 11.7, Xfce, AMD Ryzen 4750u with integrated graphics in a Thinkpad T14 AMD Gen 1). The message list highlighting is just as responsive as the folder list now. It still uses quite a bit of CPU when moving the mouse over the list, however, it's snappy and responsive now - the lag I was experiencing before seems to be completely gone.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#56 |
(In reply to Adi from comment #46)
> Version 102.12.0 seems to have fixed the issue on my setup (Debian 11.7, Xfce, AMD Ryzen 4750u with integrated graphics in a Thinkpad T14 AMD Gen 1). The message list highlighting is just as responsive as the folder list now. It still uses quite a bit of CPU when moving the mouse over the list, however, it's snappy and responsive now - the lag I was experiencing before seems to be completely gone.
I spoke too soon. A few hours later, it has degraded back to the old state. Nothing changed, it just started performing poorly again. I've also rebooted the computer, didn't run anything besides Thunderbird, and there is nothing I can do to get it fast again.
It seems the only time it was ever fast was immediately after upgrading the version from apt, no reboot. It was definitely fast and smooth for a few hours. Maybe this gives a hint? Just the fact that it CAN be fast? The CPU usage seems to be the same, but UI responsiveness is very different.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#57 |
Tested with a clean profile and TB 115 and I still see the same high CPU usage as with all previous beta releases. Is there anything we can do to help move this higher in the priority list of the developers?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#58 |
After another minor version upgrade, it was fast again. Upon switching to a new folder, it became slow, and remained slow.
I managed to capture 2 profiles, where you can see fast vs slow, same instance of Thunderbird, only difference is having switched to another mail folder then back to the original one.
fast:
https:/
slow:
https:/
Maybe this means something to someone, but to me it doesn't even seem to be related to WebRender.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#59 |
(In reply to Adi from comment #49)
> slow:
> https:/
activity in nsIAbDirectory.
Also, are you using the cardbook addon? Problem reproduces without it?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#60 |
(In reply to Wayne Mery (:wsmwk) from comment #50)
> (In reply to Adi from comment #49)
> > slow:
> > https:/
>
> activity in nsIAbDirectory.
> Also, are you using the cardbook addon? Problem reproduces without it?
I owe you a beer :-)
Disabling cardbook add-on has resolved my lagging message list. It's not perfect, but it's fast now. If I toggle the message pane with f8, make the window really wide, it's still laggy, but I never use Thunderbird this way, and the lag is nothing compared to the lag I had with cardbook enabled.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#61 |
In my case, I have no add-ons installed and tested with an clean profile. Compared to Thunderbird 91 the UI is laggy and uses about a factor 2 more CPU when hovering over the entries in the message pane.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#62 |
(In reply to Frank from comment #52)
> In my case, I have no add-ons installed and tested with an clean profile. Compared to Thunderbird 91 the UI is laggy and uses about a factor 2 more CPU when hovering over the entries in the message pane.
indeed, CPU usage is high and it's not as snappy as with version 91, but it's much better than I was experiencing, where UI would take about 250ms to update because of the cardbook addon. I still hope it gets fixed properly.
Also, it's not only the messages pane which is laggy. If you stretch the folders pane to be really wide, that one is laggy as well.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#63 |
I tried to narrow this down a bit and made tests with several versions including beta releases. For me the problem starts when switching from
**88.0b3** (snappy, fast)
to
**89.0b1** (slow, high cpu usage)
I was trying to build a version for all the commits (revisions in mecurial?) in between to narrow it down further but was only successful for the latest 115 version so far. I'll keep trying, though. If someone could confirm, that the "laggyness" was introduced in between those versions, this would already be quite helpful. Archived releases can be found here: https:/
And if someone is more familiar with building Thunderbird and mercurial (hg) version control, maybe he/she can help out building the revisions in between those releases?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#64 |
The automation of https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#65 |
(In reply to Wayne Mery (:wsmwk) from comment #55)
> The automation of https:/
This helped, thank you! I was able to narrow it down a bit further to
```
48:20.61 INFO: Last good revision: 036520a38d2b3d4
48:20.61 INFO: First bad revision: 0f4f1c5ca5d305d
```
So some commit in between 2021-01-27 and 2021-01-28 in the codebase of firefox or thunderbird is causing the issue. However *mozregression* then does not find any builds in between and stops with
```
48:27.72 INFO: There are no build artifacts for these changesets (they are probably too old).
```
Now for the Firefox code base, that means **399** revisions and for Thunderbird **20**. 😮💨
Any suggestions how to tackle this further?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#66 |
Is this still reproducible with the latest 115.2 release?
We went through some pretty in-depth optimization and it should behave much better.
Even more improvements are on the horizon in the upcoming betas.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#67 |
With these settings reverted back to normal
> gfx.webrender.all
> gfx.webrender.
>
> Switch the first one to false (it was already switched to false) and the second one to true (I switched this one manually)
> everything works smooths and no cpu usage jumps happen.
I can still reproduce unusual high CPU usage. There is no perceptible lag, but CPU usage still jumps to about 75 % on my end. To compare, continuous scrolling of websites in Firefox, even complex ones, consumes less than 25 % of CPU.
So, the claim “behave much better” might be true, but the mouse-over effect still seems excessively wasteful of resources.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#68 |
I just tried the latest 118.0b4. The lag on the mouse-over effect as well as the high CPU usage is still reproducible for me. First I thought the new "cards view" is better, but that's just because fewer messages are visible in the message pane at a given time. As has been pointed out before, reducing the TB window size to show fewer messages also reduces the effect in the classic table view.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#69 |
Tested TB 119.0b6 and still the same problem as described in my previous comment.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#70 |
(In reply to Frank from comment #39)
> I tried the latest Thunderbird 112 beta 6 and unfortunately the situation is still the same. I also managed to capture a profile of simply moving the mouse cursor vertically across the message pane window. My CPU usage goes up to 25% (on a 4-core CPU) while doing so: https:/
Geoff, does this reveal anything useful?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#71 |
Not to me, but it might to some GFX people. Although they'd probably prefer a more recent profile.
(In reply to Sebastian from comment #56)
> This helped, thank you! I was able to narrow it down a bit further to
> ```
> 48:20.61 INFO: Last good revision: 036520a38d2b3d4
> 48:20.61 INFO: First bad revision: 0f4f1c5ca5d305d
> ```
These correspond to [these changes in mozilla-central](https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#72 |
That's a quite old area of the code. You would be best served by just trying to bisect it further down to the individual patch. I can't really predict what would be causing that that far back.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#73 |
Here is a more recent profile with TB 120b5 in case it helps. As before, the profile was taken while moving the mouse cursor vertically across the message pane (no clicking or any other action): https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#74 |
Reporter (794632548/adm), does this still reproduce for you?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#75 |
(In reply to Wayne Mery (:wsmwk) from comment #65)
> Reporter (794632548/adm), does this still reproduce for you?
Yes, in 102.13.1 (64-bit) from 10% CPU to 50% when mouse hover over e-mail list. I am not using newer Thunderbird due to an appearance issue inside it (missing c0ntent of the TB window after some time) etc. for that please quote other people who had same issue.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#76 |
(In reply to Frank from comment #64)
> Here is a more recent profile with TB 120b5 in case it helps. As before, the profile was taken while moving the mouse cursor vertically across the message pane (no clicking or any other action): https:/
The expert julienw on matrix writes, " the DisplayList operation seems to take long but I don't know why"
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#77 |
I just re-installed TB 115.6.0 from scratch on a completely new Laptop (Lenovo Carbon X1 Gen 11) running Ubuntu 22.04 and I see exactly the same behavior there as on my old laptop. I will have to revert to TB 91 as any newer version is essentially unusable for me.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#78 |
(In reply to Frank from Matrix and #68)
> I narrowed it down to a change between Thunderbird 110_0b4 and 111_0b1.
That's good work.
Bad news: the number of [Firefox](https:/
Good news: 111.0b1 is the first beta with Supernova code. So there is a high chance the cause is Supernova code whose first daily build is 2023-01-16.
Bad news: I'm guessing the cause is straight up Supernova "ash" massive code landing on 2023-01-17. So you might try **nightly** builds on either side of 2023-01-17. If the problem is not seen there, use mozregression to try **nightly** builds between and 2023-02-27
(above comment edited to remove duplicate text)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#79 |
Frank ... comment 62 may render my comment 69 null and void, if the comment 56 regression range is in fact accurate. And I am skeptical of that [mozilla-central regression range 2021-01-27 to 2021-01-28](https:/
You could copy your production profile that you are using for beta to a new profile for nightly builds, to leave your beta profile unaffected by testing.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#80 |
Thanks Wayne. I think the confusing part in this ticket is that there must have been multiple regressions in terms of CPU over time and I think we are also mixing X and Wayland (in case that matters). Certainly I also saw a big slowdown between TB 91 and 102.
In any case, with regards to my specific problem (mouse hover lagging behind in Supernova) I narrowed it down to:
```
2:47.23 INFO: Narrowed nightly regression window from [2023-01-18, 2023-01-20] (2 days) to [2023-01-18, 2023-01-19] (1 days) (~0 steps left)
2:47.23 INFO: Got as far as we can go bisecting nightlies...
2:47.23 INFO: Last good revision: 76f62fd3a780925
2:47.23 INFO: First bad revision: ac5c72f2e56036e
2:47.23 INFO: Pushlog:
https:/
[...]
2:54.34 INFO: There are no build artifacts for these changesets (they are probably too old).
```
Visually the GUI changed drastically between these two builds (colors, icons, etc.) so I assume this is the massive "ash" code landing you mentioned?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#81 |
> Thanks Wayne. I think the confusing part in this ticket is that there must have been multiple regressions in terms of CPU over time and I think we are also mixing X and Wayland (in case that matters). Certainly I also saw a big slowdown between TB 91 and 102.
Very possible.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#82 |
So we are talking an important necessary change in screen update procedures if I get that right, which I would assess being independent from X vs. Wayland?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#83 |
(In reply to Wayne Mery (:wsmwk) from comment #72)
> > Thanks Wayne. I think the confusing part in this ticket is that there must have been multiple regressions in terms of CPU over time and I think we are also mixing X and Wayland (in case that matters). Certainly I also saw a big slowdown between TB 91 and 102.
>
> Very possible.
And, if it got even worse in version 115, If you using imap and are able, please try beta https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#84 |
(In reply to Frank from comment #71)
> Thanks Wayne. I think the confusing part in this ticket is that there must have been multiple regressions in terms of CPU over time and I think we are also mixing X and Wayland (in case that matters). Certainly I also saw a big slowdown between TB 91 and 102.
Mixing them probably is OK, as long as they starting date of their behavior is the same. As for slowness starting between 91 and 102, I'm not sure what that would be. There are extremely few performance issues reported in that time period that were ever confirmed.
> In any case, with regards to my specific problem (mouse hover lagging behind in Supernova) I narrowed it down to:
> ```
> 2:47.23 INFO: Narrowed nightly regression window from [2023-01-18, 2023-01-20] (2 days) to [2023-01-18, 2023-01-19] (1 days) (~0 steps left)
> 2:47.23 INFO: Got as far as we can go bisecting nightlies...
> 2:47.23 INFO: Last good revision: 76f62fd3a780925
> 2:47.23 INFO: First bad revision: ac5c72f2e56036e
>...
> Visually the GUI changed drastically between these two builds (colors, icons, etc.) so I assume this is the massive "ash" code landing you mentioned?
Yes, this is when the bulk of supernova code landed. A couple of the remaining performance issues associated with that have been fixed in 128. How does 128 perform for you?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#85 |
794632548, how is 128 for you?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#86 |
It's still the same problem in 128.0.1esr for me. CPU usage goes to 100% when moving the mouse across the message list.
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
My Linux Arch/Manjaro TB package was just upgraded: thunderbird/ thunderbird jumps from 2% of the CPU core to the 30-60% of the CPU core.
78.14.0-0.1 -> 91.1.0-0.1
and immediately i have noticed the new feature/issue:
in the unified Inbox i am moving mouse up/down quickly through the list of e-mails and i can see that the line the mouse is on is highlighted with delay, meaning that this highlight action may be not optimized/badly made or CPU heavy.
And i think that my XFCE tray CPU usage meter is showing that the CPU usage rise when i move the mouse through the list of e-mails.
I can confirm this by running "htop" in terminal, F4, type "thund", enter now move cursor in thunderbird and i can see that the CPU usage of the /usr/lib/
Expected results:
Feature optimized to have nearly no performance impact or removed.