-
Notifications
You must be signed in to change notification settings - Fork 44
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
RFE: Improve ement's memory footprint #299
Comments
Ement's design is simple: events come in, and they are stored in memory until the session is disconnected, then references to them are (or should be) removed so they can be GC'ed. If your Matrix sessions remain "connected" (in quotes since Matrix's design means a series of repeated connections, rather than a single, constant connection) for weeks or months, then, sure, the memory usage is going to go up as events are received. You shouldn't need to restart Emacs to clear Ement's memory usage; just disconnect from the sessions you're connected to. Then you could reconnect and only the events received upon initial sync would be in memory. Also, if you keep room buffers open indefinitely, then as they grow, I suppose it could begin to take longer to insert new events into the buffers--though that generally shouldn't be the case, since insertion of new events happens starting at the bottom, so if it does, it might indicate a bug. Regardless, rooms with open buffers have events inserted into them as they arrive, which is more work than just receiving the events and storing them in memory, so if you're not actually looking at a bunch of room buffers, it's probably a good idea to kill them and then reopen them when you need them. That would both reduce the time taken to process new events and reduce memory usage. Someday we might try to use SQLite to cache received events, and that might allow us to more easily discard some subset of received events from memory. But that would be a long-term goal, not likely to happen anytime soon. Also, I'd guess that much of the data usage reported in those buffers is actually data structures which are shared among them, since the Other than that, I don't know why the By the way:
Yeah, last time I ran it, it seemed quite slow, and I eventually C-g'ed it. That command is fairly new in Emacs and it probably needs optimization. Ah, yes,
I'd guess that generating the report itself probably uses a not-insignificant amount of memory, as it probably uses hash tables to count unique objects, or something like that. So it probably causes a lot of GC's, which probably makes it slow. So I'd guess that, in that case, Ement is probably using 300-400 MB of memory at that time (although since |
Thanks for the detailed explanation. I don't know why I'm restarting Emacs to "solve" this problem; I believe I might have tried restarting Ement but found that it didn't help. Anyway, I'll make sure to try again to see what happens. I understand that it may take a long time to implement a better way to store events, but thanks for considering it! I don't plan on stop using Ement anytime soon, so I can wait :-). |
OS/platform
GNU/Linux
Emacs version and provenance
GNU Emacs 29.4.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2024-07-16
I built my own Emacs.
Emacs command
emacs server + client
Emacs frame type
A mix of both (but I only use ement on GUI)
Ement package version and provenance
0.15.1, from ELPA
Actions taken
Like many Emacs users, I leave mine open for several days/weeks/months. Ever since I started using ement, I've been noticing Emacs getting slower and slower over time, to the point where the best "fix" is to restart it.
I haven't tried to tweak any garbage collector settings, but I don't think that's where the problem lies. It seems like all this memory (see below) is actually being used, so there's nothing to be collected.
Observed results
I ran
memory-report
, which took almost 1 hour to gather all data (!!!). This is what I saw:Expected results
I'd like to be able to keep using Emacs without having to restart it :-).
Backtrace
No response
Etc.
I compile my own Emacs, but I try to stick to upstream's release branch and that's what I've been using on my two main machines. On both, I see the same symptoms.
The text was updated successfully, but these errors were encountered: