In groups and channels with thousands of members, opening any screen that shows the member list could briefly freeze the app. The most noticeable case was the Chats with members screen: closing a member's chat and returning to the list reloaded everyone and stuttered each time.

The app was re-checking every member against every other member while loading the list — work that grows with the square of the group size, so it got dramatically slower as groups grew. It now does this in a single pass, so member lists, @-mentions, channel relays and adding members all stay responsive even in very large groups. You see exactly the same members, in the same order — just without the lag.

Technical detail

setGroupMembers is the shared in-memory member loader. After fetching members it merged them with the connection stats already in memory using currentMembers.find { it.id == newMember.id } inside .map {} — an O(n) scan inside an O(n) map, i.e. O(n²). GroupMember.id is a computed property ("#$groupId @$groupMemberId") that allocates a fresh String on every access, so this was also on the order of n² string allocations plus the resulting GC pressure.

This indexes the current members by id once (associateBy { it.id }) and looks them up in O(1) — same result set, no behavioral change (member ids are unique within a group), just O(n).

Rationale and verification: plans/2026-06-09-perf-group-members-merge-on2.md.