Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] High CPU use when connecting #74

Closed
Kabouik opened this issue Apr 8, 2021 · 7 comments
Closed

[Bug] High CPU use when connecting #74

Kabouik opened this issue Apr 8, 2021 · 7 comments
Assignees

Comments

@Kabouik
Copy link
Contributor

Kabouik commented Apr 8, 2021

nmail seems to be heavy on CPU when connecting to an account. In most cases it is a non-issue because the connection is quick, but it can be more annoying if nmail is launched when actually offline. I suspect this high CPU demand is a bug and not really a necessity?

ss-2021-03-30_150113

@d99kris
Copy link
Owner

d99kris commented Apr 9, 2021 via email

@d99kris d99kris self-assigned this Apr 9, 2021
@Kabouik
Copy link
Contributor Author

Kabouik commented Apr 10, 2021

  1. I've been using nmail since a long time and rarely launch it when offline so I can't tell if it was happening at the beginning, but it's definitely months at least.
  2. A lot, we're in the 7500 and 1700 range for the two accounts in the above screenshot, respectively. Both of them also have thousands of emails in other folders that are in the local cache, but those folders are not set as inbox in main.conf so I don't know if they may have an influence. I'll try tomorrow on the same machine with some less cluttered accounts or just with changing the inbox folders in main.conf to see if it's related.
  3. I use the default values, except for addressbook_encrypt set to 1.

While nmail is quick to load compared to any other email client I tried, it's not exactly 200 ms in my case. This is something that I assume is related to the size of my inbox, since it seems to be quicker with accounts with small inbox. I feel that the initial fetching speed is affected even if the last fetch was fairly recent and just a few new emails came in (subsequent fetchings when nmail is already running are quick).

@d99kris
Copy link
Owner

d99kris commented Apr 10, 2021 via email

@d99kris
Copy link
Owner

d99kris commented Apr 24, 2021

Hi @Kabouik - some performance improvements have been implemented now, in the latest couple commits (up to v3.32 / b5479f9). There is still some room for further improvements, but the last step will require major rework, so it wont happen too soon. Please let me know how you find the latest version w.r.t. performance.

Do note that the recent code changes implements a new type of offline cache (based on sqlite rather than simple file-based). So any old cached messages will be cleared, for nmail to build a new cache.

@Kabouik
Copy link
Contributor Author

Kabouik commented May 8, 2021

Thanks @d99kris for the hard work! As discussed in a chat, I observed (much) longer quit times after the change when encryption is enabled, which I assume are related to the fact that my cache/ folder and its individual subfolders are rather big.

Since this is probably associated with the time it takes to re-encrypt the folder and delete temp/, maybe an additional status for "Encrypting" in the top right would be welcome, so that users have a feedback when hitting the quit keybind and seeing nmail becoming unresponsive for some time. What do you think?

Regarding performance itself, with encryption enabled and large folders, there might be a regression since nmail is less responsive than it was with plain .eml. But CPU load may be lower, and I know that nmail is now much faster with small folders and/or encryption disabled, which is the recommended setting. There are also other advantages like exporting encrypted folders is now possible.

@Kabouik
Copy link
Contributor Author

Kabouik commented May 8, 2021

Also, related:

Not sure if related to the above or to my large full-sync being partly incomplete, but I observe "Fetching" much more frequently than before

Hm maybe we can change the status message for reading cache, so at least it's more clear whether it's fetching from server or reading from cache.. there shouldn't be more time spent doing either now though..

@d99kris
Copy link
Owner

d99kris commented Dec 11, 2021

Let's track the performance improvements for encrypted cache under #88 and close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants