perf(#306): batch per-contact setting loads instead of notifying 600 times
Diagnosed from the app's own log. After SELF_INFO the client went completely silent for 43.7s, then flushed a burst of radio frames all sharing the identical timestamp - queued while the event loop was blocked, not a slow radio. Cause: loadContactCache() looped over every cached contact calling _ensureContactSmazSettingLoaded and _ensureContactCyr2LatSettingLoaded, and each of those notified on completion. With 300 contacts that is 600 notifyListeners() calls in a burst, each rebuilding the whole widget tree, and each rebuild itself walks the contact list. O(contacts^2) on the UI isolate. Both loaders are now awaitable and take notify: false for bulk use. loadContactCache awaits them all and notifies once. Measured on the reporting device (radio 4f6585264e, TCP): 300 contacts, 1090 discovered contacts, 12 channels holding 1841 messages, 6.9 MB prefs file. Log evidence: 43.7s stall between "Pulled battery" and the first channel response, followed by same-millisecond frame delivery. This is the Windows-visible freeze in #306. The platform asymmetry is consistent with contact-list size rather than anything desktop-specific, so whether Android is genuinely faster or simply has a smaller address book on its paired radio is still open - #306 stays open pending a like-for-like re-measure. flutter analyze clean, dart format clean, 469 tests pass.integration/290-306-335
parent
2c80be3244
commit
7f9f6ba63b
Loading…
Reference in new issue