Skip to content

Conversation

@alexjba
Copy link
Contributor

@alexjba alexjba commented Nov 10, 2025

POC (haven't manually tested all the models)

We're currently suffering badly from perf issues related to how we build the nim models, how we share data between nim components, how we update the models and how we emit model update signals.
Long story short I could identify 5 model patterns in the app:

  • Pattern 1. Simple model that owns the data. Updated in bulk (model reset) or granularly. The type of model is the easiest to approach since we can do a diff and efficiently emit qt signals.
  • Pattern 2. Simple model with nested model that owns its data. This kind of model is a bit more difficult than Pattern 1, but the nested models could be fixed with the same approach. The trick is not to create new nested model objects, but to efficiently update the existing ones
  • Pattern 3. Simple model with data owned by a delegate (in our case the data owner is the service). This type of model lacks a proper way to efficiently update the model because on every delegate.get we're getting the current state. To do an efficient update we'll need the previous version of the data.
  • Pattern 4: Nested models with data owned by a delegate. AKA perf killers
  • Pattern 5: Models exposing QObjects. These models usually have a single role exposing a QObject. Probably the right way to do it would be to use Pattern 1

The current codebase is just too large to refactor all the models we currently have, so a middle-ground needs to be found and applied.

This PR is a proposal for this middle-ground.

Proposal:

Pattern 1 - apply a helper (model_sync) that does a data diff and composes a list of bulk operations needed by the model for the update. dataChanged, rowInserted, rowRemoved etc.
Pattern 2 - apply the model_sync for both main model and the nested models
Pattern 3 - Introducing a CoW container. This container is owned by the service and shared with the app. The app will have a ref to the container. Whenever data is written in the container, the service object will change, leaving all copies with the old data. This way on every update the models will have a chance of constructing the proper events using model_sync.
Downsides- we can't support ref object for the base data type (usually a DTO). We need deep copies on every write. Not a major drawback though since the container itself is supposed to be efficient and the other copies needed through the app should be relatively small.
Pattern 4 - Same as Pattern 3, with a nested model_sync
Pattern 5 - similar to pattern 1 and 2

Files of interest:

src/app/core/cow_seq.nim
src/app/modules/shared/model_sync.nim

@status-im-auto
Copy link
Member

status-im-auto commented Nov 10, 2025

Jenkins Builds

Click to see older builds (18)
Commit #️⃣ Finished (UTC) Duration Platform Result
✖️ a489f8f #1 2025-11-10 15:13:40 ~7 min tests/nim 📄log
a489f8f #1 2025-11-10 15:16:24 ~10 min macos/aarch64-nwaku 📄log
✔️ a489f8f #1 2025-11-10 15:18:30 ~12 min ios/aarch64 📦pkg
✔️ a489f8f #1 2025-11-10 15:19:57 ~13 min tests/ui 📄log
✔️ a489f8f #1 2025-11-10 15:21:44 ~15 min macos/aarch64 🍎dmg
✖️ a489f8f #1 2025-11-10 15:24:21 ~18 min linux/x86_64 📦tgz
✔️ a489f8f #1 2025-11-10 15:30:43 ~24 min linux/x86_64-nwaku 📦tgz
✖️ a489f8f #1 2025-11-10 15:33:27 ~27 min windows/x86_64 💿exe
✔️ b596219e #1 2025-11-10 15:16:46 ~10 min android/arm64 🤖apk 📲
✔️ cb3f7b11 #2 2025-11-11 17:24:52 ~9 min android/arm64 🤖apk 📲
✔️ 1a7d0603 #3 2025-11-12 17:35:44 ~19 min android/arm64 🤖apk 📲
✔️ a6e53413 #4 2025-11-13 17:26:56 ~11 min android/arm64 🤖apk 📲
✔️ 50a515c4 #5 2025-11-14 17:27:34 ~12 min android/arm64 🤖apk 📲
✔️ 8a895789 #6 2025-11-15 17:27:31 ~12 min android/arm64 🤖apk 📲
✔️ 4e88d541 #7 2025-11-17 17:27:07 ~11 min android/arm64 🤖apk 📲
✔️ f5779d12 #8 2025-11-18 17:27:12 ~11 min android/arm64 🤖apk 📲
✔️ efa963db #9 2025-11-19 17:25:08 ~9 min android/arm64 🤖apk 📲
f3eb8b55 #10 2025-11-20 17:23:50 ~8 min android/arm64 📄log
Commit #️⃣ Finished (UTC) Duration Platform Result
✔️ d7e6c3c2 #11 2025-11-21 17:27:53 ~11 min android/arm64 🤖apk 📲
✔️ 552ef684 #12 2025-11-22 17:27:46 ~12 min android/arm64 🤖apk 📲

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants