RFE: Toggle membership events on/off (per channel, ideally)

[sergiodj]

Hi,

The other day I viewed a room which wasn't very large, but I noticed that it took ement several seconds to display it. This was unusual behaviour, so I decided to profile Emacs and understand what was going on. I noticed that almost half of the CPU time was spent processing membership events.

I like having membership events displayed in some of the rooms I'm in, but I would gladly turn them off on most of them. I've been reading ement's code, more specifically ement-room--format-membership-events and ement-room--pp-thing, to see if I can hack it and make it ignore the events. I'll submit a PR when I have something.

Thanks.

[phil-s]

See also https://github.com/alphapapa/ement.el/pull/247

[alphapapa]

Yes, #247 should solve the performance problem.

@sergiodj I've been using Ement for years, including in rooms like #matrix-hq:matrix.org, which has over 30,000 members. Until Arto reported the problem mentioned in #247, I had never heard of a situation in which there were so many membership events that it was a performance problem. So the problem you're reporting seems also unusual, and so I'd ask you to provide more information about the room and its events so we can understand what's going on. Just turning off membership events would probably not be a good solution, and I'd prefer not to add another option like that unless it were really necessary.

[sergiodj]

Thanks, @alphapapa.

I find it strange, too. For me, this only happened so far in rooms bridged with Heisenbridge. I wonder if it's because membership events are much more common on IRC (i.e., people who don't use bouncers tend to disconnect at night, plus the many "connection reset by peer" problems).

To give you an example, when I opened my #emacs @ libera.chat room for the first time today it took about 10 minutes for ement to process everything (meanwhile, my Emacs was blocked waiting). Upon looking at the backlog that was loaded, I see roughly 1000 membership events (most of them being joined, left or a combination of the two).

I don't know what else I can provide, but please let me know if you think of something.

Thanks.

[alphapapa]

I find it strange, too. For me, this only happened so far in rooms bridged with Heisenbridge. I wonder if it's because membership events are much more common on IRC (i.e., people who don't use bouncers tend to disconnect at night, plus the many "connection reset by peer" problems).

To give you an example, when I opened my #emacs @ libera.chat room for the first time today it took about 10 minutes for ement to process everything (meanwhile, my Emacs was blocked waiting). Upon looking at the backlog that was loaded, I see roughly 1000 membership events (most of them being joined, left or a combination of the two).

That would seem to suggest that there were about 1,000 membership events in the same span of time that there were about 30 message events (AFAIR the Matrix server tries to send about the last 30 message events in a room upon initial sync). That seems unusual, but maybe it's not...? I mean, I used to join #emacs:libera.chat when it was bridged via Libera's Matrix bridge, and I never had any problems remotely like this. So I wonder if it's something to do with the bridge involved.

Anyway, please try the branch in question and let me know how well it performs with opening that room. If it's still too slow, I guess we'll have to figure out a way to disable membership events in certain rooms.

[sergiodj]

Thanks for the reply.

I will probably be able to give the branch a try tomorrow, and will report back my findings.

Either way, I still believe it would be beneficial to have the ability to silence membership events from certain channels. I understand that this may be considered a low priority request, though.

[alphapapa]

It sounds simple enough: just disable membership events for a room. But there's a lot more to it than that:

1. UI. It probably means making new commands to toggle them on and off (and they should probably be generic enough to toggle other event types in the future). Those probably need to appear in the room transient menu as well, with bindings, and dynamic labels to show the status.
2. On the back end, we have to decide how to persist the data. We could use a custom event type in the room's account data, but if possible, we should try to integrate with existing specifications or apps (e.g. does Element support this? If so, can we use the same data on the backend to represent the setting?). If we have to make our own event type, we have to decide whether to make it just for membership events, or whether to store a list of event types to disable. And maybe instead of just disabling them, we want to have an option to...handle them differently, I don't know (other event types might end up with an option to handle them more quietly or something).

Given all that, it would probably only take a few minutes to write some advice functions that you could use to ignore membership events in certain rooms. They could sit in your config and solve this problem for you immediately. Then, eventually, something like this could be implemented in a flexible, extensible way suitable for the long-term.

[sergiodj]

Thanks for replying and considering the feature.

Sure, in theory I could solve every problem by advising functions and so on, but it would be great to have features implemented on Ement as well.

Cheers.

[alphapapa]

Sure, in theory I could solve every problem by advising functions and so on, but it would be great to have features implemented on Ement as well.

What I'm trying to convey is that it would probably take about 5 lines of code to solve this problem in your config temporarily with advice; and that I wouldn't expect this kind of feature to be implemented in Ement itself anytime soon, because my to-do list is quite long. So if it makes the difference between being able to use it in that kind of chat room or not...it's up to you. :)