Support #295

High CPU usage in some folders

Added by Antonio Ospite almost 5 years ago. Updated 9 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



I reported the issue on the mailing list some time ago:

I still experience the problem with 3.7.0 so I am posting here,
hoping to see if anyone else can reproduce the issue.

It's some time that Sylpheed on my Debian unstable machine
takes a lot of CPU when exploring some folders with a lot of messages.

Some details on my setup:
Sylpheed Version 3.7.0 (Build 1185)
GTK+ 2.24.32 / GLib 2.54.3
Operating System: Linux 4.14.13-1-amd64 (x86_64)
Compiled-in features: gthread IPv6 iconv compface GnuPG OpenSSL LDAP GtkSpell

CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Disk: Seagate Barracuda 7200.12
Video card: "ATI Radeon HD 5670" (xorg radeon driver)

I can consistently see the behavior with "htop" or the Gnome system
monitor when I navigate my "alsa-devel" and "linux-input" mailing list
folders in Sylpheed, I can trigger the problem going to the next unread
message with the "Next" UI button.

Usually Sylpheed performs some disk activity but I've never seen this
very high CPU usage before.

From a quick "perf" run it looks like most of the time is spent here:

85,55% sylpheed [.] gtk_tree_store_get_path
12,58% sylpheed [.] g_node_nth_child

I tried to recreate the .sylpheed_cache and .sylpheed_mark file in the
affected directories but nothing changed.

The Mail dir is on the local disk (a normal HDD but it shouldn't
matter), and the problem happens also with Sylpheed in off-line mode.

A self compiled binary from the latest svn trunk shows the same

Has anyone else noticed anything similar recently? Initially I thought
it could be caused by some update in dependency libraries in Debian, but
there was no update to gtk2 recently, and I tried to downgrade glib to
a previous version but with no changes.

I also tried with a Debian stable live image (Stretch 9.2 with Sylpheed
3.5.1) to exclude that the culprit was a recent update in Debian
unstable and the behavior is confirmed on Debian stable as well.

So it seems to be the data; could it just be that these particular
folders reached some limit Sylpheed is not comfortable with?

Just for reference Claws-mail 3.15.1 does NOT show the problem in the
same folders.

Please let me know any other info you might need.

If you want access to the Mail data which shows the problem here are the
steps to download the data and replicate the issue:

1. Get the mailing list data (it's about 850MB):

$ wget "" -O alsa-devel.mbox

replacing USERNAME with "alsa-devel at" and PASSWORD with
"mailinator" in the link above. I am not pasting a full working link
to reduce the risk of spamming the alsa-project server.

I can share off-list an alsa-devel.mbox.bz2 file of about 163MB.

2. Import the alsa-devel.mbox file into a new folder in Sylpheed.

3. Click on the new folder in the folders view and go to the next
message with the "Next" button.

You can see a very high CPU usage.

Now that I think of it I might have imported data into the affected
folders from the mbox archives at so maybe the
imported data is confusing Sylpheed (but not Claws-mail apparently)?
Just a thought.

Or could it be some Gtk2 regression, in particular with my video card?
I am not sure how likely this is.



Updated by Antonio Ospite over 4 years ago

Has anyone been able to replicate the issue? I am still experiencing it.


Updated by Antonio Ospite about 4 years ago

OK, looked again into this.

A seemingly harmless message put me on the right track.

When launching sylpheed on my system I was getting this on the console:

$ sylpheed
Gtk-Message: 10:22:24.441: Failed to load module "atk-bridge"

The message goes away after installing libatk-adaptor, but the high CPU
usage problem remains.

However this gave me a hint.

Since I am using the maybe uncommon gnome-flashback session, I started
to suspect that the session itself was doing something which affected
GTK2 apps.

Checking the environment I saw:

$ env | grep GTK

And I noticed that disabling gail and atk-bridge makes the problem go

So for now I am launching sylpheed in this way:
$ GTK_MODULES='' sylpheed

And I have a usable state again.

I'll try to look for the root cause of this problem but for now it feels
nice to have found a workaround.

Ironically, accessibility features made sylpheed next to unusable in my



Updated by Antonio Ospite about 4 years ago

Ah and, in case your session does not set GTK_MODULES, the latest findings
should also make the problem reproducible by running:

$ GTK_MODULES=gail:atk-bridge sylpheed

Please let me know if someone manages to reproduce the issue.



Updated by Kentaro Hayashi about 4 years ago

I could reproduce a similar issue on my PC (sylpheed 3.7.0-4 debian/sid and even though current master)
(I'm not collecting profile yet, so just say a similar issue, GTK_MODULES="" also works as a workaround)

and in my environment, it will occur with deep nested threads (10 or more re:re:re replying are good test cases) easily.


Updated by Antonio Ospite about 4 years ago

Thank you for confirming the issue Kentaro-san.

The scenario seems to be the same: deep nested threads.

I am convinced that this is a gtk2 issue rather than a problem in
sylpheed itself, so feel free to close the issue if you think so too.

I will try to report the issue to gtk developers but —up to now— I was
not able to recreate the issue with a minimal gtk program using
GtkTreeStore and GtkTreeView and populating rows synthetically.

I still don't understand the exact reason why the issue was not
occurring in Claws, I know they are still using some custom gtk tree
code, but I don't know the details.

If you get the chance, join the #sylpheed IRC channel on Freenode so
that we can have a chat about it.

Or I can attach the program here.



Updated by replica watches 9 months ago Muller noted are for of style traditional watch wide Muller market. Franck Muller watch look you a cash. false can stylish, inexpensive.

Also available in: Atom PDF