Skip to main content

​
Performance

Group send: directed LID-PN probe in get_devices_from_registry (#823) Each call to get_devices_from_registry resolves a Jid to its canonical lookup keys before hitting the device registry cache. Previously, the key resolver (resolve_lookup_keys) only received the bare user string. It blindly probed both directions of the LID-PN map — get_phone_number then get_current_lid — for every group member. This resulted in 3 moka lookups per participant before the registry lookup. Server-aware probe. A hot caller in get_devices_from_registry already holds the full Jid, and the namespace fully determines which direction is meaningful:
  • A LID user (@lid) can only appear in the lid → pn map.
  • A PN user (@s.whatsapp.net) can only appear in the pn → lid map.
The new resolve_lookup_keys_for_jid dispatches on the JID’s server field and probes exactly one direction for LID/PN JIDs. All other namespaces keep the existing two-probe fallback. This turns 3 cache operations per member into 2 with no change in the resulting canonical keys.
A concurrent-resolution prototype (buffered(50) stream, mirroring WA Web’s SESSION_CHECK batching) was measured and rejected: 962 µs vs. 675 µs serial for a warm 800-member send (+43% slower). Moka hits resolve immediately, so there is no I/O to overlap and the stream machinery is pure overhead. The reliable gain comes from doing less work per member, not reordering the same work.
Benchmark (release, warm caches, 800 members × 2 devices, 500 iterations):
Warm 800-member send
Before (blind two-probe)675 µs
After (server-aware probe)497 µs (−26%)
No breaking changes. get_devices_from_registry keeps its existing signature; the directed probe is an internal implementation detail.