Support #295

High CPU usage in some folders

Added by Antonio Ospite 7 months ago. Updated 2 months ago.

Status:NewStart date:02/07/2018
Priority:NormalDue date:
Assignee:Hiroyuki Yamamoto% Done:


Category:SylpheedSpent time:-
Target version:-



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.



#1 Updated by Antonio Ospite 2 months ago

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

Also available in: Atom PDF