perf(#307): count rail filters in one pass over contacts
From the Gemini pre-PR review (standards#145). ContactFilterRail computed each row's count with its own `where().length`, so the contact list was walked once per filter. On a ~350-contact radio that is ~2100 iterations, re-run on every MeshCoreConnector notification, and those arrive per packet during sync. Now a single pass fills all six counts, and the per-contact unread lookup happens at most once instead of once per filter. Also documents why context.select is NOT used in ChannelDrawerList, since the review recommended it: `channels` is `List.unmodifiable(_channels)`, a fresh instance per call, and Dart lists have no value equality, so select would rebuild exactly as often as watch. Selecting on `length` instead would go stale on a rename or reorder. watch is correct here; the comment records that so the next reader does not re-litigate it. Review findings not acted on: - Claimed BLOCKER (context across an async gap in _blockChannelSender) is a false positive: `mounted` guards are already present at :614 and :618 and the messenger is captured before the await. It is also pre-existing code from #172, not this branch. - _lastChannelSendAt not cleared on channel switch: real behavior change, but the suggested fix is questionable. That field is a send cooldown protecting the radio, so clearing it on switch would let the limit be bypassed by hopping channels. Raised with the owner rather than changed unilaterally. flutter analyze clean, dart format clean, 445 tests pass.pull/324/head
parent
746e102330
commit
7dd0e2b633
Loading…
Reference in new issue