Navigating the message listAs 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 = 0With 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 paneIn 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 #271So 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 thunderbirdThis 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 settingsI 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.