Navigating the message list

As you navigate the message list with the arrow keys, thunderbird will display the message contents and mark the message read, even if you don't lift your finger off the key. I.E. you can't skip messages by holding the up/down key. This is strange interface behaviour and I'm unsure why thunderbird does this. Well by default you can skip messages by holding the arrow keys, but one implication is that thunderbird adds a delay before selecting a message so that you can navigate the message list without selecting each message. However that delay is very annoying in the normal case where you're advancing to the next message. The default delay is 250ms which is very noticeable and distracting. To disable that, set the following value to 0 in the config editor, on the general tab in preferences.

mailnews.threadpane_select_delay = 0

With that set you'll get responsive display of each message, but have issues when skipping messages with the arrow keys? You can do this by holding the Ctrl key, which is a standard mechanism used in GTK+ lists at least.

Avoiding stalls when scrolling the folder pane

In Sep 2012 I updated from thunderbird 6 to thunderbird 15 on my Fedora 15 distro, but immediately hit a huge issue with stalls when scrolling the folder pane. Downgrading to version 6 again avoided the stalls, though I needed to use a later version for various reasons. After I "upgraded" to thunderbird 17 in Feb 2013, the stalls actually got worse. It's surprising there are interface stalls at all given the number of threads that thunderbird uses:

ps -C thunderbird -L 
  PID   LWP TTY          TIME CMD
30474 30474 ?        00:49:39 thunderbird
30474 30490 ?        00:00:00 Gecko_IOThread
30474 30491 ?        00:00:37 Socket Thread
30474 30492 ?        00:00:11 JS GC Helper
30474 30493 ?        00:00:01 JS Watchdog
30474 30494 ?        00:00:00 Hang Monitor
30474 30495 ?        00:00:00 Cache2 I/O
30474 30496 ?        00:07:42 Timer
30474 30498 ?        00:00:00 gdbus
30474 30500 ?        00:00:00 HTML5 Parser
30474 30502 ?        00:00:00 mozStorage #1
30474 30503 ?        00:00:00 Analysis Helper
30474 30504 ?        00:00:00 Analysis Helper
30474 30505 ?        00:00:00 Analysis Helper
30474 30506 ?        00:00:00 Analysis Helper
30474 30509 ?        00:00:00 DOM Worker
30474 30518 ?        00:00:00 Cert Verify
30474 30519 ?        00:00:00 URL Classifier
30474 30520 ?        00:00:00 dconf worker
30474 30521 ?        00:00:00 Proxy R~olution
30474 30523 ?        00:00:00 mozStorage #2
30474 30527 ?        00:00:00 Cache I/O
30474 30534 ?        00:00:00 mozStorage #3
30474 30538 ?        00:00:00 mozStorage #4
30474 30630 ?        00:00:00 gmain
30474 30637 ?        00:00:00 localStorage DB
30474 31705 ?        00:00:00 threaded-ml
30474 31707 ?        00:00:00 DOM Worker
30474 31710 ?        00:00:00 mozStorage #5
30474 31768 ?        00:00:00 MediaManager
30474  3832 ?        00:00:00 mozStorage #6
30474  3846 ?        00:00:00 Image Scaler
30474 11846 ?        00:00:00 mozStorage #7
30474 15251 ?        00:00:00 DNS Res~er #271

So let's leverage the power of open source and profile the thunderbird code. We'll need to install debuginfo to get symbols etc. and this is very large at about 2G for Fedora 21, but can be uninstalled when finished. After running these commands:

sudo yum install perf
sudo debuginfo install thunderbird
sudo perf top -g -p $(pidof thunderbird)

we get this profile for when thunderbird is stalling:

Notice the morkmap::find() and other morkmap functions at the top of the profile when the stall happened. Note the scrolling of the folder pane is otherwise CPU intensive which confuses things, but it seems to be the morkmap functions that stall thunderbird. A little searching suggested that these functions are for interacting with the external/persistent msf index files and these will be regenerated automatically when needed. So I moved all of the old msf files like:

# stop thunderbird
cd ~/.thunderbird/*.default/
mkdir old_msf
# Backup just in case
find Mail/ -name "*.msf" -print0 |
xargs -r0 cp --parents --target=old_msf
find Mail/ -name "*.msf" -delete
# start thunderbird

This worked! No more stalls. The size of the regenerated files is about the same, so the issue seems to be content rather than size. A caveat is that threading and column preferences are lost for each folder, though that's a small price to pay to avoid the stalls. Note also that thunderbird is using less memory in recent versions (and less with these new regenerated indexes), though that doesn't seem directly related to the stalls. Note also, not to touch the ImapMail/ msf files as these seem to have additional data other than just indexes. In any case it was only the msf files in Mail/ that were causing the stalls for me.

Other performance settings

I have also disabled smoothscroll as that takes 25% of my i5 CPU to scroll the message which is overkill for what it provides.

I've also disabled the "Global search an indexer" option which consumes huge amounts of CPU and storage, at least initially to index message bodies. This is also overkill for me as one can easily search the message bodies in a particular folder which caters for 99% of my usage at least.