[upstream] Very high CPU and slow responsiveness in Thunderbird 91-102

[Daniel van Vugt]

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.force-disabled = TRUE

Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1730423

[Adm-e (adm-e)]

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.
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/thunderbird/thunderbird jumps from 2% of the CPU core to the 30-60% of the CPU core.

Expected results:

Feature optimized to have nearly no performance impact or removed.

[Adm-e (adm-e)]

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/Folders/Unified
but the issue happen also in normal folders.

[Vseerror (vseerror)]

Please create a profile using https://support.mozilla.org/en-US/kb/profiling-thunderbird-performance

Thanks

[Adm-e (adm-e)]

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.

[Vseerror (vseerror)]

(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?

[Arnauld-s (arnauld-s)]

(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.

[Adm-e (adm-e)]

I wanted to post a proof video what i am doing and the issue i am seeing, [here please](https://streamable.com/xocz74)

[Debaser-1 (debaser-1)]

Related concerns found in [Archlinux forum](https://bbs.archlinux.org/viewtopic.php?pid=1994387) and [Reddit r/Thunderbird](https://old.reddit.com/r/Thunderbird/comments/ppnb5g/thunderbird_91_significantly_slower/).

[Debaser-1 (debaser-1)]

https://share.firefox.dev/3ENDDXi

[Atlantida (skrall666)]

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][DispatchAsyncMessage] Error: PClientManager::Msg_ExpectFutureClientSource Processing error: message was deserialized, but the handler returned false (indicating failure)

Other errors include:

ERROR style::stylesheets::rule_parser] Saw @import rule, but no way to trigger the load

(xfce4-panel:659): xfce4-panel-CRITICAL **: 18:26:19.276: panel-window.c:2391 (panel_window_active_window_geometry_changed): expression 'WNCK_IS_WINDOW (active_window)' failed.
JavaScript error: resource:///modules/AddrBookCard.jsm, line 166: NS_ERROR_NOT_AVAILABLE: PreferDisplayName: undefined - not a boolean

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.

[Atlantida (skrall666)]

This one also:

JavaScript error: resource://gre/modules/ActivityManager.jsm, line 129: NS_ERROR_NOT_AVAILABLE:

This is on Arch (XFCE).

[Cdcwvbjibv (cdcwvbjibv)]

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)

[Vseerror (vseerror)]

Changing severity to S3 because of modest performance

[B-fabian (b-fabian)]

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://support.mozilla.org/en-US/questions/1347196#answer-1435915

> If I go to preferences --> config editor and search for the entries:
>
> gfx.webrender.all
> gfx.webrender.force-disabled
>
> 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/severity. People upgrading seldom backup their Thunderbird profile and when this happens, all the usual "Thunderbird is slow" are being tried without a solution, bringing a user closer to stop using Thunderbird and go to other options.

A few references to people reporting this problem :

* https://support.mozilla.org/en-US/questions/1347196
* https://support.mozilla.org/en-US/questions/1351874

[B-fabian (b-fabian)]

More reports :

* https://www.reddit.com/r/Thunderbird/comments/ppnb5g/thunderbird_91_significantly_slower/
* https://bbs.archlinux.org/viewtopic.php?pid=1992824

[Sfoerster42 (sfoerster42)]

The workaround worked for me (GNU/Linux).

[2-axel (2-axel)]

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.

[Completelyrandom+github (completelyrandom+github)]

I was the author of the previously mentioned thread in the ArchLinux forum (comment [#7](https://bugzilla.mozilla.org/show_bug.cgi?id=1730423#c7) and [#14](https://bugzilla.mozilla.org/show_bug.cgi?id=1730423#c14)).

Just dropping by to confirm: The workaround quoted in comment [#13](https://bugzilla.mozilla.org/show_bug.cgi?id=1730423#c13) works for me.
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.

[Bugzilla-mozilla-org (bugzilla-mozilla-org)]

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/thunderbird-wayland 91.1.0-1.fc34.x86_64 (installed from RPM).

[Buhrt (buhrt)]

The workaround seems to 'fix' Thunderbird 91.1.0 Fedora 34 (thunderbird-91.1.0-1.fc34.x86_64). I ran the performance profiler before the change with and without add-ons enabled and saved the respective json files along with screenshots from the 3 profiler tabs if anyone wants/needs them.

[Vseerror (vseerror)]

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?

[Cdcwvbjibv (cdcwvbjibv)]

Reporting on additional unwanted behavior which doesn't get resolved using the workaround mentioned in comment [#13](https://bugzilla.mozilla.org/show_bug.cgi?id=1730423#c13).

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).

[Cdcwvbjibv (cdcwvbjibv)]

(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://bugzilla.mozilla.org/show_bug.cgi?id=1730423#c13).
>
> 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).

[Daniel van Vugt (vanvugt)]

Downstream Ubuntu bug: https://launchpad.net/bugs/1959747

[6-valentin (6-valentin)]

I confirm this on the most recent distributions of Arch Linux and Thunderbird.

The suggested fix works to solve the sluggishness.

[Bll-guayam-gj5 (bll-guayam-gj5)]

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.force-disabled" to "true" (and confirming "gfx.webrender.all" to be "false"), moving the mouse over either the message list or the folder list results in high cpu usage and much sluggishness; I can easily move the mouse more than fast enough to have the "hover highlight" not be able to keep up.

[RAJDEEP RAJESH THAKARE (rajdeep-thakare)]

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.

[Daniel van Vugt (vanvugt)]

I'm having similar problems again in 1:91.9.1+build1-0ubuntu0.20.04.1 with Thunderbird's CPU usage well over 100% and long periods of not responding since the update.

But the fix for the original problem is still active:

  gfx.webrender.all = false
  gfx.webrender.force-disabled = true

[Daniel van Vugt (vanvugt)]

If I revert the above settings then the problem gets even worse. So it seems we might have multiple different 100% CPU bugs now.

[UlfZibis (ulf-zibis)]

I'm having similar problems in 1:91.10.0+build1-0ubuntu0.20.04.1 with Thunderbird's CPU usage well over 25 % and for long periods and additionally causing root process Xorg to consume 15 % CPU.

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1772673

A workaround for me is:
  gfx.webrender.force-disabled = true

Because of this bug: https://launchpad.net/bugs/1950044
I have installed this PPA: https://launchpad.net/~savoury1/+archive/ubuntu/display?field.series_filter=focal
Maybe, this is the source for the current problem.

[UlfZibis (ulf-zibis)]

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://bugzilla.mozilla.org/show_bug.cgi?id=1772673#c11

[UlfZibis (ulf-zibis)]

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.

[Martin Sivak (mars-montik)]

Same here on Fedora 36, Thunderbird 91.8.0 (64 bit).

[Vseerror (vseerror)]

More interesting, is can anyone reproduce this when using version 102? from https://www.thunderbird.net/

Webrender is much improved in version 102 for Windows. Perhaps it is also better for Linux.

[M-mozilla-org (m-mozilla-org)]

I can reproduce this on Fedora 36 with Thunderbird 102.2.0 on Wayland.
Setting `gfx.webrender.all false` and `gfx.webrender.force-disabled true` doesn't reduce CPU usage for me.

[M-mozilla-org (m-mozilla-org)]

A capture documenting this bug with Thunderbird 102.2 on Linux (Fedora 36, Wayland): <https://share.firefox.dev/3wAF2hd>
Between 1.5s and 4.5s the mouse pointer is moving over the message list.

[adibadi (adibadi)]

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.

[Soeren-hentzschel (soeren-hentzschel)]

> 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.software to true to disable hardware WebRender and enable software WebRender instead. Please try this instead of using an e-mail client with security vulnerabities (since Thunderbird 91 won't receive any further security update we have to assume that Thunderbird 91 is insecure now).

[adibadi (adibadi)]

(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.software to true to disable hardware WebRender and enable software WebRender instead. Please try this instead of using an e-mail client with security vulnerabities (since Thunderbird 91 won't receive any further security update we have to assume that Thunderbird 91 is insecure now).

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://share.firefox.dev/3y3PfU2

[Frank Winklmeier (frank-winklmeier)]

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.

[Vseerror (vseerror)]

(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://share.firefox.dev/3y3PfU2

According to experts in matrix chat, "https://share.firefox.dev/3UR69z3 (profile from comment 32, we don't have symbols so I collapsed libxul.so). The profile from comment 29 has symbols, so we can see a bit more what happens: https://share.firefox.dev/3y7gOMy Both profiles show too much time drawing SVG images (and too many Image Paint markers for these images). The profile from comment 32 additionally has an insane amount of time spent doing an SQL query from getCardFromProperty. From looking at the profiles, it's not obvious to me if the SVG images are repeated too many times because of a Thunderbird bug, or if they are painted too many times due to a graphics bug."

[Thibaut Vandervelden (thvdveld)]

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://share.firefox.dev/3CCIknA

[Mozilla-c (mozilla-c)]

> 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 :)

[Mozilla-c (mozilla-c)]

> 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

[Vseerror (vseerror)]

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.

[Frank Winklmeier (frank-winklmeier)]

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.

[Frank Winklmeier (frank-winklmeier)]

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://share.firefox.dev/3zvwCZH

[Seb45tian (seb45tian)]

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://share.firefox.dev/3MNOpmA

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 :-/

[mgw (michaelweigelt)]

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...force-disabled) from the configuration. Reintroducing the parameter helps but doesn' fix the time out.

All this happend after latest upgrade to 102 w/ no changes in configuration.

[Mw-c (mw-c)]

(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://support.mozilla.org/en-US/questions/1347196#answer-1435915
>
> > If I go to preferences --> config editor and search for the entries:
> >
> > gfx.webrender.all
> > gfx.webrender.force-disabled
> >
> > 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/severity. People upgrading seldom backup their Thunderbird profile and when this happens, all the usual "Thunderbird is slow" are being tried without a solution, bringing a user closer to stop using Thunderbird and go to other options.
>
> A few references to people reporting this problem :
>
> * https://support.mozilla.org/en-US/questions/1347196
> * https://support.mozilla.org/en-US/questions/1351874

The mentioned parameter (gfx...force-disabled) is gone from configuration in 102 . Reinstating the parm helps some but doesn't fix the 100% CPU utilization. (5.15.0-52-generic #58~20.04.1-Ubuntu SMP on Intel Core i7-2760QM)

[Vseerror (vseerror)]

(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://share.firefox.dev/3MNOpmA

nsTreeBodyFrame::PaintCell
nsTreeBodyFrame::PaintImage
nsMsgDBView::GetCellProperties

[Frank Winklmeier (frank-winklmeier)]

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...

[Mw-c (mw-c)]

Did anybody try to start with a clean profile restoring previous and reproduce the error?

[Frank Winklmeier (frank-winklmeier)]

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).

[adibadi (adibadi)]

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.

[adibadi (adibadi)]

(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.

[Frank Winklmeier (frank-winklmeier)]

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?

[adibadi (adibadi)]

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://share.firefox.dev/3NPoVnU

slow:
https://share.firefox.dev/3PZLCbH

Maybe this means something to someone, but to me it doesn't even seem to be related to WebRender.

[Vseerror (vseerror)]

(In reply to Adi from comment #49)
> slow:
> https://share.firefox.dev/3PZLCbH

activity in nsIAbDirectory.cardForEmailAddress ?
Also, are you using the cardbook addon? Problem reproduces without it?

[adibadi (adibadi)]

(In reply to Wayne Mery (:wsmwk) from comment #50)
> (In reply to Adi from comment #49)
> > slow:
> > https://share.firefox.dev/3PZLCbH
>
> activity in nsIAbDirectory.cardForEmailAddress ?
> 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.

[Frank Winklmeier (frank-winklmeier)]

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.

[adibadi (adibadi)]

(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.

[Seb45tian (seb45tian)]

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://archive.mozilla.org/pub/thunderbird/releases/

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?

[Vseerror (vseerror)]

The automation of https://mozilla.github.io/mozregression/quickstart.html will make the job much easier

[Seb45tian (seb45tian)]

(In reply to Wayne Mery (:wsmwk) from comment #55)
> The automation of https://mozilla.github.io/mozregression/quickstart.html will make the job much easier

This helped, thank you! I was able to narrow it down a bit further to
```
48:20.61 INFO: Last good revision: 036520a38d2b3d46fb31cf93f89d3545242feac5 (2021-01-27)
48:20.61 INFO: First bad revision: 0f4f1c5ca5d305dd600f759c69737e43478e6777 (2021-01-28)
```
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?

[W-alessandro (w-alessandro)]

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.

[Completelyrandom+github (completelyrandom+github)]

With these settings reverted back to normal

> gfx.webrender.all
> gfx.webrender.force-disabled
>
> 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.

[Frank Winklmeier (frank-winklmeier)]

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.

[Frank Winklmeier (frank-winklmeier)]

Tested TB 119.0b6 and still the same problem as described in my previous comment.

[Vseerror (vseerror)]

(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://share.firefox.dev/3zvwCZH

Geoff, does this reveal anything useful?

[1-geoff (1-geoff)]

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: 036520a38d2b3d46fb31cf93f89d3545242feac5 (2021-01-27)
> 48:20.61 INFO: First bad revision: 0f4f1c5ca5d305dd600f759c69737e43478e6777 (2021-01-28)
> ```

These correspond to [these changes in mozilla-central](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=42791e22621d1dab5fff576448eccb45f6b3ca6a&tochange=37557864a6845bb8068904e44e8a7dd16746d211). Jamie and/or Lee, would you have a look at the profile from comment 39 and see if you find anything interesting? (I'm picking on you because I don't know any GFX people and you both made changes in the regression range which might be related. Sorry!)

[Lsalzman (lsalzman)]

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.

[Frank Winklmeier (frank-winklmeier)]

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://share.firefox.dev/3QzNmHl

[Vseerror (vseerror)]

Reporter (794632548/adm), does this still reproduce for you?

[Adm-e (adm-e)]

(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.

[Vseerror (vseerror)]

(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://share.firefox.dev/3QzNmHl

The expert julienw on matrix writes, " the DisplayList operation seems to take long but I don't know why"

[Frank Winklmeier (frank-winklmeier)]

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.

[Vseerror (vseerror)]

(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://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FIREFOX_110_0b4_RELEASE&tochange=FIREFOX_111_0b1_RELEASE) and [Thunderbird](https://hg.mozilla.org/releases/comm-beta/pushloghtml?fromchange=THUNDERBIRD_110_0b4_RELEASE&tochange=THUNDERBIRD_111_0b1_RELEASE) patches in that span is massive.

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)

[Vseerror (vseerror)]

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://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2023-01-27+06%3A00%3A00&enddate=2023-01-28+08%3A00%3A00). But you might try nightly builds in that date range.

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.

[Frank Winklmeier (frank-winklmeier)]

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: 76f62fd3a78092592457e19dbc6e59f87c4f084d (2023-01-18)
 2:47.23 INFO: First bad revision: ac5c72f2e56036e2088b5aa794891978fcede5aa (2023-01-19)
 2:47.23 INFO: Pushlog:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=76f62fd3a78092592457e19dbc6e59f87c4f084d&tochange=ac5c72f2e56036e2088b5aa794891978fcede5aa
 [...]
 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?

[Vseerror (vseerror)]

> 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.

[Mw-c (mw-c)]

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?

[Vseerror (vseerror)]

(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://www.thunderbird.net/en-US/download/beta/ and report your results.

[Vseerror (vseerror)]

(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: 76f62fd3a78092592457e19dbc6e59f87c4f084d (2023-01-18)
> 2:47.23 INFO: First bad revision: ac5c72f2e56036e2088b5aa794891978fcede5aa (2023-01-19)
>...
> 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?

[Vseerror (vseerror)]

794632548, how is 128 for you?

[Frank Winklmeier (frank-winklmeier)]

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.