fix(backup-performance): message creation - WPB-20905

[David-Henner]

WPB-20905 [iOS] Backup performance :: creating messages

Issue

Using the time profiler with a backup sample of ~15k messages, I observed that 34% of the time importing a backup is spent doing a fetch request to fetch messages we’re importing. (in MessageLocalStore.fetchOrCreateClientMessage)

However, since we’re already checking if messages exist before creating them (as part of backup import), we don’t need to try to fetch them, we just need to create them.

Solution

Add methods:

• MessageLocalStore.createClientMessage
• MessageLocalStore.createAssetClientMessage

And use these when processing messages from the backup in ConversationProtobuMessageProcessor.processProtobufMessage

Result

Measured the performance of importing a backup of ~15k messages, using a baseline build with no performance improvements and another build with the improvements from this PR (#3694) + the current PR.

Metric	Baseline	Optimized	Times Faster
Total time	8.90 min	3.81 min	≈ 2.34×
Page processing (1k messages)	33.37 s	14.28 s	≈ 2.34×
Message processing (individual average)	19.81 ms	13.33 ms	≈ 1.49×
Restoring last read	183.6 s	12.23 s	≈ 15.0×

Note: The change from this PR (#3694) was between 1,2 - 1,31 times faster

---

Checklist

• Title contains a reference JIRA issue number like [WPB-XXX].
• Description is filled and free of optional paragraphs.
• Adds/updates automated tests.

[github-actions]

Test Results

    6 files    637 suites   10m 26s ⏱️
3 827 tests 3 798 ✅ 28 💤 1 ❌
3 829 runs  3 801 ✅ 28 💤 0 ❌

For more details on these failures, see this check.

Results for commit 71e3224.

[caldrian]

Could you please make the purpose of this flag somehow more clear?
E.g. leave a doc comment somewhere when the flag should be set to true or false.

Also we could rename it somehow, like
skipFetching...
skipChecking...
alwaysCreate...
...?
or similar.

[samwyndham]

+1

[David-Henner]

good point ! I was considering introducing a configuration object with flags such as skipFetching as I may need to introduce more conditions

[samwyndham]

LGTM. Nice performance improvement.

[samwyndham]

+1

[samwyndham]

However, since we’re already checking if messages exist before creating them (as part of backup import), we don’t need to try to fetch them, we just need to create them.

question: If this checking somehow fails, what would happen if we attempt to create a message when it already exists?

[David-Henner]

However, since we’re already checking if messages exist before creating them (as part of backup import), we don’t need to try to fetch them, we just need to create them.

question: If this checking somehow fails, what would happen if we attempt to create a message when it already exists?

Since there's no uniqueness constraint on the message entity in core data, it would create a duplicate entry in the db