CPU usage is very high

[msjsc001]

Please agree to the following

• I have searched existing issues for duplicates
• I agree to follow this project's Code of Conduct

Summary

CRYPTOMATOR's CPU usage is very high

What software is involved?

• Operating System: Windows11 23H2
• Cryptomator: 1.12.4
• OneDrive: 24.050.0310.0001(64bit)
• Logseq(Markdown editor): 0.10.8
  • https://github.com/logseq/logseq/tags
• CPU: AMD Ryzen 7 3700X 8-Core Processor

Volume Type

WinFsp (Local Drive)

Steps to Reproduce

When using the Markdown note-taking software Logseq to type and write notes, CRYPTOMATOR's CPU usage is very high, ranging between 15%-90%, even when OneDrive is paused.

This is a problem that's currently causing me a lot of frustration, as it makes note-taking very laggy. At the moment, I have to use WinFsp (Local Drive), which is a virtual disk format software, in order to properly use git. Additionally, the disk location of my CRYPTOMATOR files has BitLocker enabled. My git only syncs every half hour, so it's unlikely to be the cause of the issue.

Expected Behavior

When taking notes, the CPU usage won't be high (my CPU performance is considered good for a home computer).

Actual Behavior

CRYPTOMATOR's CPU usage is very high

Reproducibility

Always

Relevant Log Output

No response

Anything else?

No response

[hpvd]

same here, starts after update to 1.12.4 It's not always there but starts after a time. Maybe something like a virusscan is triggered by some new behaviour of cryptomator and leads to high read load?

[msjsc001]

I'm not sure what's causing it either. Recently, when using the Cryptomator virtual disk with Logseq, it has been extremely laggy, while it becomes smooth when using it outside the Cryptomator virtual disk! Here are some of my personal speculations. Using Cryptomator to encrypt note files before uploading them to a cloud drive is a very useful feature, and note-taking is a function that many people use every day, so it's hoped that this bug can be fixed.

It's possible that the lag is caused by Cryptomator's instant encryption and file locking. I suspect that it's highly likely that when using the Logseq note-taking software, every keyboard stroke causes an update to the .md file, and after the .md file is updated, Cryptomator immediately encrypts the corresponding .md file, leading to particularly high CPU usage (an average person might strike the keyboard 5 times per second, so Cryptomator might have to perform 5 encryptions per second). Additionally, after each keyboard stroke, Cryptomator likely locks the .md file that's currently in use for encryption purposes, causing the software to be unable to read the .md file, resulting in extreme lag (this type of note-taking software has the ability to instantly read and write .md files after editing, and being unable to read them would cause lag, as note-taking software designed for multi-device and multi-sync would not lock .md files). This way, it's highly possible that the instant encryption and file locking after each keyboard stroke causes the Logseq note-taking software to become extremely laggy and Cryptomator to consume a particularly high amount of CPU resources (of course, this is just my personal speculation).

It's possible that the lag is caused by large files in Cryptomator. When using a small Logseq repository (with only a few .md files) with the Cryptomator virtual disk, there's no lag, but when using a large Logseq repository (with many .md and other files) with the Cryptomator virtual disk, there's extreme lag and high CPU usage. Perhaps Cryptomator encrypted the files in the large repository into a relatively large encrypted file, so every keyboard stroke requires updating this large file?

It can be confirmed that similar software, not just note-taking software, would definitely be affected as well.

[overheadhunter]

I suspect that it's highly likely that when using the Logseq note-taking software, every keyboard stroke causes an update to the .md file, and after the .md file is updated, Cryptomator immediately encrypts the corresponding .md file, leading to particularly high CPU usage (an average person might strike the keyboard 5 times per second, so Cryptomator might have to perform 5 encryptions per second).

Cryptomator keeps up to 5 * 32k bytes cached, so consecutive reads/writes near the same position don't cause constant I/O to the regular file system. However it really depends on the I/O operations performed on the VFS. If an app requests flushing after every single write, Cryptomator will obey. You can enable debug logging to see the operations.

That said, I suspect the cause must be something else, since we didn't change much to the FS recently but this report suggests this is a new issue. Furthermore, can you check whether this only affects WinFsp (Local Drive)?

[hpvd]

i think this are to different things:

1. cryptomator is/was always relatively slow even in comparison to the very old boxcryptor which is doing the same file and name encryption before upload to the cloud, see Volume is super slow #3170 (comment)
   cryptomators advantage:
   • it is well maintained and
   • maybe it's a more robust or more secure implementation?
2. with the latest version there is something triggering high cpu load from time to time, but maybe this is not the new version but a "feature" resulting from latest windows updates combined with cryptomator

[overheadhunter]

There are reports about high CPU usage on macOS as well, however there we are talking about 2-3% instead of 0% when idle, which I suspect is a UI bug and we are currently investigating.

This report looks more about an I/O bottleneck, though.

[msjsc001]

I suspect that it's highly likely that when using the Logseq note-taking software, every keyboard stroke causes an update to the .md file, and after the .md file is updated, Cryptomator immediately encrypts the corresponding .md file, leading to particularly high CPU usage (an average person might strike the keyboard 5 times per second, so Cryptomator might have to perform 5 encryptions per second).

Cryptomator keeps up to 5 * 32k bytes cached, so consecutive reads/writes near the same position don't cause constant I/O to the regular file system. However it really depends on the I/O operations performed on the VFS. If an app requests flushing after every single write, Cryptomator will obey. You can enable debug logging to see the operations.

That said, I suspect the cause must be something else, since we didn't change much to the FS recently but this report suggests this is a new issue. Furthermore, can you check whether this only affects WinFsp (Local Drive)?

I have tested all the virtual disk modes except Dokany, and they all occasionally have issues with high CPU usage and lag in note-taking software. The disk usage is not high when the problem occurs.

Additionally, I am using a high-performance M.2 SSD and a relatively powerful CPU. I was wondering if it's possible for the GPU to share some of the processing load to alleviate potential lag issues caused by high CPU usage. This is just an amateur idea, but I thought it might be helpful.

Currently, WinFsp has the best overall compatibility, so I have chosen to use it.

[hpvd]

hmm the amount of data to be processed after a key stroke should be tiny..
Or do you have large files where you add things?
Can you reproduce is starting with an empty new file??

[msjsc001]

hmm the amount of data to be processed after a key stroke should be tiny.. Or do you have large files where you add things? Can you reproduce is starting with an empty new file??

Normally when lag occurs, all I'm doing is typing, so I suspect it's caused by keystrokes, without any other file operations.

As long as the Logseq library has a large number of .md format note pages, this problem can be reliably reproduced on both new pages and old note pages, especially when continuously entering text or hitting enter and then entering more text.

The Chinese input method I use enters about 3 English letters after I press about 3 keys, and after selecting the Chinese characters in the candidate box, those 3 English letters are deleted, leaving 2 Chinese characters. When typing quickly, I can input 2-4 Chinese characters per second, but as you said, the amount of text processing should be extremely small, so it's unclear what's causing this.

[dstark]

I seem to be having the same issue when writing Markdown with Zettlr into and out of a Cryptomator vault. CPU by the Cryptomator process is very high (60–95%). Changes also seem not always (never?) to save properly.

Windows 10 and 11, Cryptomator 1.12.4, Zettrl 3.0.5.