ec66f3b21e
The purpose of this change is to alleviate the main source of CPU-grinding after sending a message to a large group: about 20% of the total time is spent decoding and re-encoding messages as they are fetched from the DB and then updated with info about which recipients have acknowledged delivery. Prior to this commit, we decrypted the payload and then processed the message in a single rather deep call tree that began in `processNextBatch`. There are two completely different paths through this tree that lead to handling a delivery receipt because server-generated delivery receipts have the necessary info in plaintext in the envelope and client-generated delivery receipts have it in the ciphertext. The idea here is to break incoming envelope handling into two parts. In the first part, each envelope is decrypted and other common activities (like handling sender key distribution messages) are performed. A processing request is created for each. Next, processing requests are handled. It's easy to examine a processing request to determine if it is a delivery receipt, and if so, for what outgoing message. Doing so allows the new DeliveryReceiptContext class to cache message fetches and combine updates to the same message. Processing requests are grouped together so that sequential delivery receipt requests enjoy caching of messages and coalescing of updates into a single fetch/decode/encode/commit. Other kinds of envelopes are handled immediately to avoid increasing memory pressure that caching multiple messages could cause. |
||
|---|---|---|
| .. | ||
| Account | ||
| Contacts | ||
| Devices | ||
| Groups | ||
| Messages | ||
| Network | ||
| Security | ||
| Storage | ||
| Util | ||
| SSKBaseTestObjC.h | ||
| SSKBaseTestObjC.m | ||
| SSKBaseTestSwift.swift | ||
| SSKSwiftTests.swift | ||