High CPU usage and laggy UI with version 0.9.6

[nicolamori]

Describe the bug With version 0.9.6 I see a high CPU usage and a laggy UI every time the content of a folder is modified (a new mail arrives, a mesage is moved/deleted etc.). This lasts several seconds. Downgrading to 0.9.5 solves the problem.

To Reproduce 1) install Systray-X 0.9.6 2) move amessage from one folder to another 3) check for CPU usage and UI responsiveness 4) check that after several seconds everything is back to normal

Expected behavior CPU usage and UI responsiveness should not show any troublesome behavior.

Desktop (please complete the following information):

• OS: ArchLinux
• Architecture: 64 bit
• Desktop type / Window Manager (KDE, Xfce, Cinnamon, MATE etc): Plasma
• Thunderbird version and arch (Tb xx.xx.x, 32 or 64 bit): 115.4.1
• Thunderbird package type (repository, mozilla binary, flatpak, snap, etc): ArchLinux [extra] repository
• Run echo $XDG_SESSION_TYPE in a terminal and report the results: x11
• Add-on version: 0.9.6
• App version
• Install type: github repository build, script installer, OBS repository: pacman package manager
• Used Qt library (default system repository, other OBS repo, self-compiled, Qt online installer): default system repository, version 5.15.11

Additional context Bug report on ArchLinux bug tracker

[Antiz96]

I confirm the bug, version 0.9.6 indeed produces a high CPU usage on a folder modification causing the Thunderbird UI to get laggy for a few seconds. I also confirm that version 0.9.5 does not have the issue.

Thanks for your work on systray-x by the way :)

[Airfan]

I also confirm it with both 115.3.1 and 115.4.1 with systray-x version 0.9.6

OS: Xubuntu Architecture: 64 bit

I also thank you for your work.

[Ximi1970]

Looks like the new count method using a new API feature for TB115 is way to slow if you have a lot of messages in a folder. Will make the new count method optional for TB115.

I really hope the TB developers would spend more time on developing a useful API instead of killing the GUI.

[Ximi1970]

I made the new used mail count for TB115 optional in branch feature-optional-count.

Did some extra testing with the disabled new mail count 0.9.6+, 0.9.5 and no addon at all under Windows 11 (Core i3- 9100T), TB 115.3.1, davmail / exchange server with 2500+ email inbox. Seems the lagging and CPU usage is Thunderbird (or davmail/exchange) related. If I move an email from the trash to the nicely filled Inbox Thunderbird hangs for about 5 seconds in my case. Does not matter if I install the addon or not.

Will also test a local imap account tonight.

[nicolamori]

In my case I have only 3 IMAP accounts, and I see no issues with 0.9.5 or with the addon not installed. So maybe you stumbled upon a different issue related to davmail?

[Ximi1970]

Yeah I think so...

[Airfan]

My IMAP account has 2.3GB of messages and my Inbox has around 12k messages. It takes around 5-6 sec for one core at max (i5-10210U) to move a message between the Inbox and a folder with 2 messages if the plugin is enabled and around 1 sec with little to no cpu usage if it is disabled.

[Ximi1970]

It is really hard for me to judge the speed in my virtual machines.... My default machines are quite fast and it looks like I optimized my mail server quite good :-) So locally I get almost no delays but can see some CPU spiking but no lag at all.

Is anyone willing to test the reverted count method? The default setting in this version is to use the old counting. In the preferences under the count tab you can find a new checkbox in the special option section to enable the TB115 new count method. In the debug console you can see which one is used when the count changes.

Packages can be found here: (The packages can be downloaded separately without adding this test repository.)

https://build.opensuse.org/project/show/home:Ximi1970:Mozilla:Add-ons:Staging:Test2

This is the zipped Arch KDE package (first unzip, then pacman -U .....):

arch.zip

[nicolamori]

I cannot trigger the bug with the Arch package you provided, neither using new nor unread message count type. Both modes work as expected. It looks like it's fixed in this version, but let's wait for feedback also from @Antiz96 .

[Ximi1970]

Thank you for testing. Great it worked! There is still no way to get the new mail count of a folder directly using the API with just one call. The TB115 method needs to load ALL the message headers to check for a new messages. It guarantees a good count and I hoped it was really fast but... So back to the old method :-)

I will wait for @Antiz96 to push it to develop.

[Antiz96]

I'm not home right now, but I'll try my best to test that soonish. If not this weekend, it'll be next week.

[Antiz96]

[...] I will wait for @Antiz96 to push it to develop.

I confirm the package you provided works as expected. No laggy issue/bug. Thanks! I'll wait for you to push to develop and update the Arch package (if you tag a new release) or backport the fixing commit on Arch side :)

Thanks once again!

[Ximi1970]

Thank you for testing. I will merge the branch to develop and start a build for the git packages. The packages can be found in:

https://build.opensuse.org/project/show/home:Ximi1970:Mozilla:Add-ons:Git

I also changed the new API count a bit. As long as you do not select any "new" message indication, it should also be fast. The "new" count made a really slow. It needs to load all the message headers.... For the new release I will also try to solve the multi window handling, still do not know if it is feasible...

[nicolamori]

@Ximi1970 It seems that having tried the package you provided for testing broke something in my system. After the tests I went back to the systray-x-kde Arch package version 0.9.5-2, but with that the unread/new email counter does not work anymore. It didn't happen when jumping forth and back from 0.9.6 to 0.9.5 Arch packages during my early tests. I had to re-install the test package and with this the count icon works again, albeit with a different color than before. It looks like jumping from one version to another messed up the configuration in some way. I can live with the test package until Robin provides a new Arch package, but I thought you might be interested in knowing this.

[Ximi1970]

"Live" switching the addon can still cause strange effects in counting. I still need to fix that in some places. Best you can do after switching is really quit TB and start again. I made a mistake in the develop branch concerning the new indicator for TB115. It did not work anymore. So there was no new mail coloring. I fixed it and started a new build for the git repository. Should be working again.

[nicolamori]

Well, actually to fix coloring it was sufficient to set the color in the settings panel. And yes, I tried to stop and start Thunderbird after going back to 0.9.5 but that didn't help. But as I said, I am happy for now with the test package so no need to rush for this. Thanks again for your support.

[Antiz96]

[...] I can live with the test package until Robin provides a new Arch package [...]

@Ximi1970 Is this commit enough on its own to solve the issue we were facing with version 0.9.6? If so, I could backport it in v0.9.6 on Arch side.

Otherwise, I can also just wait for v0.9.7 :)

[Ximi1970]

No it is not enough. This was the fix for the fix :-)

[Ximi1970]

Created a new release but the build service is down again :-(

[Antiz96]

I updated the Arch package to v0.9.7 and it works as intended for me (without the laggy UI issue) :) @Ximi1970 thanks a lot for your quick actions!

@nicolamori, would be nice if you could check that it works as intended on your side as well, so I can close the Arch ticket.

[Ximi1970]

Packages generated.

[npomarede]

Hi I add the slowdown nearly all the time with thunderbird 115.5.1 and this seemed to be fixed with systray version systray-x-0~git20231107.311dacc-22.1.x86_64.rpm

but since then the problem happens again, but more randomly. I use imap, with ~26000 mails in inbox and several thousands mails in ~100 folders. I can browse folders for a while and then problem happens when accessing a random folder.

when the problem happens, thunderbird UI becomes unresponsive and TB use the full CPU (100% in 'top')

Is there anything I can enable to get some traces of what is not working ?

[Ximi1970]

Do not use the API count method or disable the new message indicator. Problem should be solved with the next TB release. They finally added a new message attribute for a folder in the API. No need to check every message like I need to do if the API count method is enabled.

[npomarede]

both "API count method" and "show new indicator" were already disabled and I still get the bug. I will wait for next TB version then.