Mailspring has high CPU usage

There are a plethora of reports of high CPU and/or GPU usage by Mailspring, across many systems and platforms.

Hi! donā€™t use mailspring for long but i have seen no such thing. I test the app in two windows based machines with low end cpu (i5 2nd gen - i7 4th gen) and i see no more than 15-20% usage when sending something, and almost zero usage when itā€™s in the background.

The Ram usage in the background is about 300mb out of 8g

It does seem to be isolated. One thing I suspect is the length of email threads, which we already know causes massive slowdowns (see Significant Lag on Large Threads ). What is the longest email thread you have?

22 message thread with many attachments, all expanded.

0-1% cpu useage for my modest i5 2nd gen.

Nothing to worry aboutā€¦ :slight_smile:

There has to be a more specific cause, then. Weā€™ll keep looking into it. Iā€™ve tagged this as #spooky to indicate that itā€™s challenging to diagnose and/or reproduce.

I just wanted to add a data point to this thread/issues. I am seeing fairly high CPU usage with Mailspring. Itā€™s enough to keep the fan on my PC fairly high - roughly 15-20% usage. What do you need to help diagnose this?

A few things that might help to know:

  • What is your operating system (with exact version) and computer specs (RAM, CPU, etc.)
  • How many accounts do you have connected? Which services?
  • Do you have any email threads with more than 3-4 messages?
  • Do you notice the CPU usage higher at some times than others with Mailspring?
  • Is the CPU high if Mailspring is only running in the background (tray) with the window closed?

Iā€™m using Pop OS (Kernal 5.8, Ubuntu 20.10 based).
I have three accounts connected - two Gmail, one with Proton Bridge (local proxy to Protonmail)

  • I likely have lots of emails with long threads. One of my Gmail accounts is my main account that Iā€™ve had for years.
  • Mailspring usage hovers around 12% (ā€œmainā€ process) open or closed. I am using a Intel i7 4770 with 16GB RAM. This is just enough to move the CPU into a warm enough state the get the CPU fan up to the audible zone. Itā€™s not drastic but is noticeable. Given this is a 8 thread CPU (1/8 = 12%), it looks like one thread is running 100%.
  • This usage seems consistent at all times. Iā€™m looking at it now with Mailspring closed and itā€™s 12% solid.

Hope this helps.

Comparisons like this are useful. Iā€™m on a similar system to you - Pop OS 20.04, Intel i7, 12 GiB RAM, and Mailspring never gets up to large CPU consumption. I see two differences between our situations:

  • You have a Gmail account, whereas I do not. (I have a dozen email accounts, though!) Does Gmail demand more CPU somehow? (EDIT: I just linked my old, message-filled Gmail, still not using much CPU.)
  • I donā€™t have very many large threads. Most of my emails are <= 4 messages.

This is an ongoing related bug, which may in fact be what youā€™re experiencing: Significant Lag on Large Threads

I donā€™t think large threads are a problem in my case. Unless they are in issue with background processing? I just opened a large email thread (11 messages) and response from the UI was normal. In general, Iā€™m not experiencing any UI slow downs.

Iā€™m just observing the mail sync log and it seems normal. I do see the following, is it a concern?

3332 [2021-03-01 14:59:24.867] [background] [warning] [SLOW] Transaction=saveFolderStatus > 80ms (831ms, 830 waiting to aquire)
3332 [2021-03-01 14:59:24.867] [background] [info] Sync loop deleting unlinked messages with phase 1.
3332 [2021-03-01 14:59:24.869] [background] [info] Sync loop complete.

Honestly, not sure. It looks like your instance is slowing down when saving folder status, but beyond that, Iā€™m not sure. (Iā€™m not the main developer, just a heads up.)

In any case, itā€™s more data for debugging this.

To add a comment to this, I also have this. Unfortunately, it seems to just get the fans on my laptop going and drains my battery, making Mailspring a no-go for me. If it helps, a few characteristics of my system:

  • Running the latest Elementary OS, fresh install.
  • I have only one account configured
  • I have quite a long history of email in my account, likely with many multi-thread email conversations.
  • I have only used Mailspring for a week, but it still says Scanning Messages.

Iā€™m running the latest Manjaro KDE with mailspring out of the AURā€¦ This is on a 2020 Dell 9300 laptop with 16 gig of ram.

I have two IMAP accounts hooked up to it, one from Zoho and the other Icloud.

I have lots of email threads with more than 4 messages - some with dozens. i also have a huge inbox and never clear out my spam either.

CPU usage is almost always high enough to run my fans with lots of small processes soaking it up even when the main window is killed. I have to use killall mailspring to stop the fans running.

Thatā€™s more pronounced if I have other apps running but the dominant CPU hog is always mailspring.

1 Like

I can confirm the high CPU usage, but not always. When the app is running in the background, or when I only open the main Mailspring application window, everything seems to be OK.

The problem starts when I click on ā€œCompose new messageā€ on the top left and the dialog opens. The CPU usage starts growing and turns around 60-80% (reported by Htop). It does not really matter whether you open one or multiple instances of the dialog, nor how many words are there, nor what the language is (e.g. Persian or English).

Perhaps these are handled by the DE, but if you minimize (only) the dialog(s), the CPU degrades to normal levels. Or, if you keep the dialog open (i.e. not minimized) but not focused, after some time (5 minutes or so), the CPU fan spins even more for some seconds, and then the CPU usage will turn back to normal.

Nonetheless, personally I have not seen any issues related to CPU usage during sending an email.

System Information:
CPU: Intel Core-i5 6200U
RAM: 4GB
OS: Fedora Workstation 33 (Linux kernel 5.11.7)
DE: Gnome Shell 3.38.4
Environment variables: DRI_PRIME=1 (I suspect it be related)

1 Like

I can confirm high CPU usage with the latest 1.9.2 on Ubuntu 20.10 (Snap packaging). High CPU usage appears only with a simple IMAP account. Office 365 account is no problem.

It seems that I found the reason for high CPU usage with the IMAP account in my use case. In the home directory of the mail server, there existed .viminfo, .bash_history, and some other hidden files. Mailspring was trying to scan them, as well. Upon deletion of these files, the CPU utilization went down.

1 Like

My hardware and CPU usage is almost identical to this as well - 8 thread CPU w/ 12% usage (1 core) almost constantly.

3 accounts - 2 Gmail and 1 Protonmail, but the Protonmail account seems to be the issue. Fedora 35, kernel 5.15.

Has there been any progress on figuring this out?

Hello, thank you for awesome software!

I have just one issue, the CPU usage is high even while the window is not open and itā€™s only supposed to poll the mail servers every now and then and idle otherwise. I realised this while trying to figure out why my laptop battery drains faster than I expect it to.

Mailspring is using 12-16% cpu when the window is not visible and 30-40% when the window is visible.

My env/spec:
Laptop Dell 9510
CPU Intel i7-11800H 8-cores
RAM 32gb
OS Arch Linux
Mailspring latest version installed from AUR
3 email accounts - gmail, work imap, protonmail bridge

Please let me know if there is a way to gather more data about the issue

Hi guys. Iā€™m running on Manjaro i3, latest kernel, just installed it. Loving Mailspring, been using it for two years now.

I do notice performance issues when opening the composer. Specifically, the ā€˜Mailspring Composerā€™ thread seems to eat 25% of my Ryzen 5800 laptop CPU when composing longer emails (maybe Iā€™m just not noticing with shorter emails). I do use emojis. When I close it, Mailspring is silent and stays below 1% CPU.

Obviously the CPU usage eats up my battery when Iā€™m on the road, hoping this will help narrow down the issue. If I can provide you with any further information, let me know!