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

[Feature]: Improve performance when fetching a lot of history from mam #1240

Open
2 tasks done
lissine0 opened this issue Sep 16, 2024 · 1 comment
Open
2 tasks done

Comments

@lissine0
Copy link
Contributor

Precondition

  • I understood that this template is only for feature requests and not for bug reports

Cross-checked related issues?

Describe your feature

I'm using macOS (14.6.1, but it was the same on 12.x)
This is not noticeable if I open Monal daily, but if I don't open it for a couple of weeks, and I have 6 active public channels, fetching mam is heavy on the CPU (uses ~125% on my old 2-core, 4-thread CPU). It makes my fan spin :D
Also, the time it takes to finish seems slower than other clients. Though I did not make any precise measurements.
I'm using the alpha and beta release channels, and my server is a self-hosted prosody 0.12.4

@tmolitor-stud-tu
Copy link
Member

That might be because Monal uses a separate DB transaction for every incoming message stanza. Using one transaction for every incoming batch of mam stanzas (e.g. one mam page) could improve performance, but since decrypting omemo messages can sometimes take 500-1000ms, that could considerably lock up the app if applied to all catchups, not only unencrypted channels. While applying this to unencrypted channels might severly increase the complexity and decrease maintainability of our stanza handling.

There might be other parts of the app slowing down the catchup, too, that might be easier to speed up. Maybe a profiling to identify those code parts could help here.

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