* added details for Signalyzer; improved ContactsManagerCache
* some minor runtime improvements
* systems contacts are written and read in big chunks to improve overall performance
* use of __file__, __function__ and __line__ when monitoring objective C methods
* minor changes
* minor changed based on review comments
This assert was added to try and catch instances where we fail to map
the local address to the localProfile sentinel because the local address
hasn't been loaded by tsAccountManager.
We don't care about the reverse direction. There are instances at
startup where the we are fetching the localProfile using the known
sentinel before the local address has been loaded. In these instances,
we don't care that the local address hasn't been loaded since the
mapping has already been performed.
And do it sooner: at 5MB remaining instead of 1MB. This matches the
inverted condition of 20MB used, as well as where we're seeing sudden
spikes and then nothing in our logs.
This is intended to catch requests to the server that could be causing
problems in the memory-constrained environment of the NSE. It's
unlikely, since we log *all* network requests and we haven't seen any
suspicious ones, but it could still be useful in the future.
Note that this only applies to data tasks, not download tasks; a
download task can be as big as it needs to be.
Commit 451fa08c22
had some bugs and was reverted by commit
12883e5db5.
This commit brings it back along with fixes.
Specific bug fixes:
* Verification status for a group was inverted.
* The local address should not be considered for
deciding if a group is verified.
When opening a group chat we check if all
participants are verified (which confers to the
chat verified status and a "✓ Verified" label in
the header) and we also check if any participants
have the "no longer verified" status so we can
warn you about potential misdeeds.
Previously, this was done by performing a select
statement for each participant twice (once for
"are all verified" and again for "is any
no-longer-verified").
This change uses a join in a select statement
instead to reduce the number of queries performed.
Given existing indexes in the DB this can be done
efficiently. Adding additional indexes does not
seem to help - or at least I wasn't able to get
sqlite to use them.
Since most chats are not verified, we use a LIMIT
clause when possible to allow the DB to stop
early, which should make queries even cheaper.
OWSOutgoingResendResponse is *usually* resending a message that the
other party failed to decrypt, but if that message can't be found it
still tries to reset a 1:1 session or provide a missing sender key. In
these cases, it was trying to fetch the nonexistent thread by nil ID,
which was getting converted to an empty string in Swift for
compatibility reasons, which we have a debug-only `assert` to prevent
in SDS code. Just skip that step; it will come back empty anyway.
Also, sort them in the database query, so they don't need to be sorted
afterwards. (This is important for existing code that works in
batches.)
We do lose an optimization where the unread messages are counted in a
read query before marked read in a write query. If that's important I
can contrive a way to put it back.
PR 2982 optimized
ConversationViewController.createGroupMembershipCollisionBannerIfNecessary`
that fetches user profiles off the main thread and
then, when that completes, uses them on the main
thread to find duplicate display names.
The optimization doesn't work for large groups.
Because `UserProfileReadCache` is backed by an
LRUCache with a maximum capacity of 32, there is
effectively no cache and profiles get fetched
twice.
The main purpose of this commit is to fix this
optimization for large groups without expanding
memory usage unnecessarily. While increasing the
LRU cache's size to 1000 (or some other arbitrary
value) would fix the problem very simply, my gut
tells me that we're going to keep running into
this problem.
Rather than pick an arbitrary "large enough"
value, this commit increases the cache size to be
just large enough for its intended purpose and to
keep it that size for just long enough to do its
job.
This commit introduces the concept of a "lease" on
a larger cache size. The cache's size is defined
as the largest of all its leases plus its
"regular" size (the size it was initialized with).
For now only the user profile cache uses it.
Don't allocate it ahead of time, don't serialize or deserialize it
through MTLModel's NSCoding support. It's redundant with the
GroupMembership property.
While here, make comparing the members of two groups a little faster,
if not quite as simple.
