The biggest winners here are addMatrixMember() and removeMatrixMember(),
which were a hotpath of updateMatrixMemberListForRoom, called upon xmpp users
joining matrix rooms, which used to lock up the process completely for
large rooms.
On a local test with a 3000-person room, the joins went down from ~500ms
to ~200 and then ~50 once the caches warm up. The remaining time seems
to be mostly spent on IO (sending actual XMPP presence updates), and the
offending code disappears completely from a profiler output – hopefully
meaning that the bridge will have ample time to deal with other tasks
instead of locking up completely like it used to.
There are some remaining bits that iterate on indexable member lists,
though they don't seem to be a measurable performance problem for now,
so I left them as they are – but easily identifyable with the menacing
Array.from().
The biggest winners here are addMatrixMember() and removeMatrixMember(), which were a hotpath of updateMatrixMemberListForRoom, called upon xmpp users joining matrix rooms, which used to lock up the process completely for large rooms.
On a local test with a 3000-person room, the joins went down from ~500ms to ~200 and then ~50 once the caches warm up. The remaining time seems to be mostly spent on IO (sending actual XMPP presence updates), and the offending code disappears completely from a profiler output – hopefully meaning that the bridge will have ample time to deal with other tasks instead of locking up completely like it used to.
There are some remaining bits that iterate on indexable member lists, though they don't seem to be a measurable performance problem for now, so I left them as they are – but easily identifyable with the menacing Array.from().