Loading a CHW area is slow

[SCdF]

Loading a CHW area takes 10s of seconds on a reasonable phone. I imagine this is proportionate to the number of families that CHW has. It's not clear if this is just how it is, or if we're doing something inefficient.

Perhaps we shouldn't render every single family under the area in the UI straight away.

For reference:

• loading a random family: ~2.5 seconds
• loading their area: ~30 seconds

[medic-bot]

Hi @dianabarsan,

Please ensure this ticket has a Priority, Status and Type label.

(See triaging old issues for more detail)

[kennsippell]

I mapped out the Application-Database interactions along with the paint timings for the contact's tab. This is profiling just the scenario for a Muso heavy user experiencing slow performance, so there could be scenarios on the tab not profiled here. In general, things are pretty tight but there are a few optimization ideas below.

"Contacts" - Left-Panel
L1. Get org.couchdb.user:adamayo doc for the facility_id
L2. Get facility doc associated with facility_id
L3. Get all the contacts associated with the facility doc

PAINT THE CONTACTS PAGE WITH SPINNERS

L4. Use view(contact_by_type) for type "clinic" > Returns all "clinics" (40 of them for this user)
L5. Get documents of all clinics (max 50 paginated)
L6. Get clinic doc's primary contact (40)

PAINT THE LEFT PANEL

"Contact-Content" - Right-Panel

R1. Get org.couchdb.user:adamayo doc for its facility_id. Select that clinic.
R2. View(docs_by_id_lineage) for the selected clinic. Returns doc in lineage (selected clinic and area doc).
R3. Hydrate the contacts from these docs. Gets clinic doc's contact and area doc's contact.
R4. View(contacts_by_parent) for the selected clinic. Gets all children's full docs.

PAINT RIGHT PANEL WITH SPINNER
XmlForms – Queries for org.couchdb.user:adamayo doc again
PAINT RIGHT PANEL FRAMED WITH SECTIONS AND SPINNERS

R5. View(docs_by_id_lineage) for selected clinic's primary contact. Returns clinic's contact's doc and area's contact's doc.
R6. Fetch clinic's primary contact doc to sort it to top.
R7. Fetch contact information for each of the children from R4 (unsure what this data is used for? Empty in my scenarios)

PAINT CHILDREN (after 4982)

R8. View(reports_by_subject) passing in the ids of all children.
R9. Look up the docs for all the reports

PAINT THE REPORTS

Optimization Ideas
Things are pretty good for the left panel. Things are more complicated on the right and my understanding is a bit rough. That said, here are some unmeasured potential optimization ideas:

1. Adjusting when we paint right panel seems like a big win here. Alxndrsn's [wip] [2.18.x] incremental UI loading for contacts #4982
2. Can potentially completely avoid L5 if we just use "Include_docs" for L4. No measurable gain
3. Can potentially completely avoid R9 if we just use "include_docs" for R8. No measurable gain
4. There are some very small optimizations that can be made in the view map. This is a very small changes, but could reduce time to build views. No statistically significant improvement
5. We could paint the left panel after step L5 and lazy load the L6 contacts. Or we could talk about skipping L6 all together if the data is not critical. [WIP] Lazy loading content in the contact's left panel #4999 Remove "Primary Contacts" from Contact Tab LHS #5090
6. In a similar vein to the above change, we could not populate contact information for the children and completely skip R7. #5084 - Remove "Primary Contact" from RHS #5098
7. The data fetched in right-panel step R6 was already fetched in step R4. Can we consolidate? Contact RHS - Avoid primary contact lookup when redundant #5103
8. All together, this tab is fetching org.couchdb.user:adamayo 3 times. I assume this document has very low churn and it is likely safe to cache UserSettings() in a similar style to Settings() or Auth() lookups. #4445 - Cache UserSettings() lookup of org.couchdb.user #4988
9. Result for L3 is only used in the rare case where the clinic isn't already in the list (must have >50 clinics for this to ever happen). May add more complexity than it is worth, but could avoid L2 and L3. usersHomePlace.type is used by $scope.setLeftActionBar so this information is required
10. Since we don't pre-build all views for this tab, some sort of warning when they build like "The first time you see this, it can take a long time to load"
11. Left and right panels load in parallel on tablets. So on first load, contact_by_parent and docs_by_id_lineage and contacts_by_type views are all building/running in parallel. It may be a better experience to load the left panel completely before starting the right. Not prioritizing scenarios on tablets.
12. I'm expecting that debouncing should cancel existing loading content? If I rapidly click on 3 clinics, I see the Reports view finish 3 times. So I suspect debouncing maybe doesn't do what I expect, or isn't working as well as it could. Debouncing doesn't cancel requests. Mybad
13. Quick look at the CPU profile to load left panel, ~25% of load time is spent in live-list.js _update function #4445 - Reduce time to render contacts list through live-list #5016
14. PouchDB recommends doing pagination via startkey for performance reasons.

[garethbowen]

@kennsippell Good write up, thanks!

What version did you do this analysis on? There have been improvements made between the version MUSO is on and the latest and greatest, eg: #4669

Point 3: Do you mean "R9" and "R8"?

[kennsippell]

@garethbowen This is on master since Muso has a concrete timeline to get 3.2. I have displayLastVisitedDate=false.

Point 3: Do you mean "R9" and "R8"?

Yes I did! Edited above for accuracy. Are any of these things you think are higher potential, or are notinterested to pursue (eg. 5?), or have looked into already?

[garethbowen]

I like the idea of dropping the primary contact information from the LHS and RHS but this will need to be discussed with design if this is feasible or not.

Consolidation of data fetching is another one I like. Some of these decisions were made so we could have reuse of the services but we may be able to include additional parameters to keep information from being thrown away or we may have to drop the idea of reuse in favour of performance.

I'm also wondering if we could hide the Children, Reports, and Tasks sections of the Contacts RHS in an accordion (or similar) and only fetch the data when the accordion is expanded.

I wouldn't worry too much about tablets as they're not very common in the field and they generally have a bit more grunt anyway - prioritise the phone experience for now.

[kennsippell]

Recommend closing this issue - I believe all planned work is now tracked in linked issues.

[garethbowen]

@alxndrsn Did you have anything outstanding to commit against this issue, or can we close as @kennsippell suggests?