Performance
Group send:participant_list_hash uses a shared arena instead of one String per device (#822)
participant_list_hash computes the phash that travels on every group send (since #678 it is included on all sends, not just multi-device ones). Previously it collected all participant JIDs into a Vec<String> — one heap String per device — sorted them, and hashed the concatenation. For an 800-device group this was 801 discarded allocations per message on the hot send path.
Arena approach. All device JIDs are now formatted into a single shared String (the arena). A second Vec<(usize, usize)> stores (start, end) range pairs into the arena. Sorting those range pairs by &arena[start..end] is lexicographically identical to sorting the individual strings, so the resulting SHA-256 + base64 hash is byte-for-byte the same as before. The existing pinned cross-implementation test vectors (phash_crosscheck_vectors, locked against whatsmeow and WA Web) pass unchanged.
Allocation counts (release, 800 devices, 1 000 iterations):
| Allocations per call | |
|---|---|
Before (one String per device + sort) | 801 |
| After (arena + range sort, full function including SHA-256 + base64) | 3 |
Jid::push_ad_to
A new #[inline] method on Jid in wacore-binary:
user.agent:device@server) directly into an existing String buffer without allocating a new one. to_ad_string now delegates to it, keeping identical output. Use push_ad_to when batching many JIDs into a single buffer.
No breaking changes. to_ad_string output is unchanged; push_ad_to is purely additive.