High CPU usage in some folders
|Assignee:||Hiroyuki Yamamoto||% Done:|
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 libgtk-x11-2.0.so.0.2400.31 [.] gtk_tree_store_get_path
12,58% sylpheed libglib-2.0.so.0.5400.0 [.] 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
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 "http://mailman.alsa-project.org/mailman/private/alsa-devel.mbox/alsa-devel.mbox?username=USERNAME&password=PASSWORD" -O alsa-devel.mbox
replacing USERNAME with "alsa-devel at mailinator.com" 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
http://mailman.alsa-project.org/pipermail/alsa-devel/ 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.
#2 Updated by Antonio Ospite over 1 year 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:
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
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
#4 Updated by Kentaro Hayashi over 1 year 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.
#5 Updated by Antonio Ospite over 1 year 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.