Repository navigation
App performance issues #3766
Description
The following performance issue have been noticed when running the app in the field by the WDF team
- Slow loading of forms
- Slow saving of forms
Metrics
Collect the following metrics : -
- Load times for various forms
- Have a break down of the various resources
- Phone specs - RAM, CPU, storage
Activity
ajhmohammed commentedon Aug 5, 2025
The debug apk took somewhere between 3.5 to 5 seconds to load the questionnaire and 20 to 25s to save the questionnaire
The release apk took around 2 to 3.5 seconds to load the questionnaire and 10 to 15 seconds to save.
Both test carried out with different devices with different patients counts.
Example
device 1: with 49 patients
device 2: 5587 patients
ajhmohammed commentedon Aug 17, 2025
Stats from Prod Instance Release APK.
Total Number of Patients: 5624
Other Resources count
Total Number of Resources: 727342
Device Information
Available Forms and Stats (Offline Test) - Arranged in the priority order
jingtang10 commentedon Sep 8, 2025
@ajhmohammed thanks for sharing this.
can you please profile the specific api calls?
i don't think we need to do this for all questionnaires, just take a typical questionnaire for example, and just print out the timestamp before and after the questionnaire fragment call.
and to do this more systematically, we can use https://developer.android.com/studio/profile. but let's have a rough idea first.
ajhmohammed commentedon Sep 10, 2025
ajhmohammed commentedon Sep 11, 2025
After commenting out DefaultRespository.kt line no. 260
// val updateFrom = res.updateFrom(resource)
LZRS commentedon Sep 11, 2025
After profiling FHIRCore with logging additions (commit), we've identified these performance bottlenecks.
When saving a questionnaire, the
T.updateFrom(updatedResource: Resource)function, represented byupdateFromCalcTimein the logs, consistently took around 2 seconds per resource, contributing to a total time of up to 12 seconds for one of our tests that took ~14s.fhircore/android/engine/src/main/java/org/smartregister/fhircore/engine/util/extension/ResourceExtension.kt
Line 131 in 21d6d95
Logs Saving medicines questionnaire form
total ~14s 9ms
When loading a questionnaire the
ResourceMapper.populatefunction, represented byresourceMapperPopulatein the logs, took up to 5 seconds although in some occassions it could take less than 1sfhircore/android/quest/src/main/java/org/smartregister/fhircore/quest/ui/questionnaire/QuestionnaireViewModel.kt
Line 1145 in 21d6d95
and
getQuestionnaireFragmentBuilderconsistently took 1-2 secondsfhircore/android/quest/src/main/java/org/smartregister/fhircore/quest/ui/questionnaire/QuestionnaireActivity.kt
Line 418 in 21d6d95
with
questionnaire.json(),questionnaireResponse.json()andlaunchContextResources .associate { Pair(it.resourceType.name.lowercase(), it.encodeResourceToString()) }each taking ~600msLogs Loading medicines form
total ~7s 349ms
mberg commentedon Sep 11, 2025
On the loading forms
2025-09-11 00:20:11.827 9887-9887 System.out org...opensrp.diabetesCompassClinic I populationTime: => 5.235959252s
This is taking 5 seconds which is where the bulk of the slowness is. What is happening here?
mberg commentedon Sep 11, 2025
I guess that's the populate. What does that do? If that fetching the resources to prefill into the form?
LZRS commentedon Sep 11, 2025
Yeah, it populates the questionnaire with resources referenced through the
sdc-questionnaire-launchContextextensionLZRS commentedon Sep 16, 2025
The next steps of action will be
T.updateFrom(updatedResource: Resource)function and in case its needed, try to optimise and - @rkareko @LZRS @ajhmohammed (FHIRCore)Moved to a separate coroutineScope within the
defaultdispatcher thread- [ ] For loading of a questionnaire, check whether a questionnaire haslaunchContextextension to prevent redundant call toResourceMapper.populatefunction @rkareko @LZRS (FHIRCore)- [ ] In the sdc, we can add a check to only doResourceMapper.populatepopulation processing only a questionnaire has launchContext extension @LZRS (SDC)Doesn't seem to work for questionnaires using fhirpath expression
today()as an initialExpression, without definedlaunchContextextensionFor the
getQuestionnaireFragmentBuilderand for the extension functionResource.encodeResourceToString(), ensure that only a single instance ofFhirContext.forR4().getCustomJsonParser()is used, to shave off time used to initialize every time @rkareko @LZRS (FHIRCore)Explore triggering pre-initialization of the fhirPathEngine beforehand (on app start-up) to remove time taken to initialize it when loading a questionnaire @LZRS
- [ ] LaunchgenerateCarePlanandexecuteCQLinto a separate thread to not block saving @LZRSPulled back on this as some CarePlans were not getting generated in time to interact with a patient's profile
@ajhmohammed will assist with testing the effectiveness of the above steps
15 remaining items
mberg commentedon Oct 9, 2025
FikriMilano commentedon Oct 9, 2025
@mberg
My short guess is, it's because of we run PlanDefinition which generates all the tasks the patient needs (around 44 tasks) on submission of registration form. This doesn't happen on other forms.
I'll re-check registration form and get back to you on the details.
mberg commentedon Oct 9, 2025
ajhmohammed commentedon Dec 5, 2025
Hi @jingtang10 , @mberg & @rkareko, I have tested this version of the app witht the users and got a very postive feedback. Unfortunately when testing app, I found out that the auto calculated date field on the form did not auto populate after this change.
Just to make sure, i recompiled the app with the main branch and its confirmed that the performance improvement made a breaking change.
jingtang10 commentedon Dec 5, 2025
@LZRS has a fix for it I think
LZRS commentedon Dec 5, 2025
Yes, I have the fix here ohs-foundation/android-fhir#2923
Whereby the widgets UI were not getting updated for calculated expressions.
Although, I'll have to confirm if the fix works for Android views that had not been migrated to compose.
LZRS commentedon Dec 5, 2025
@ajhmohammed Could you confirm which branch you were using? I believe the performance improvement work had already been merged to the main branch
ajhmohammed commentedon Dec 5, 2025
Hi @LZRS & @jingtang10 my bad, its a wrong branch. The bug was on the branch #3804
LZRS commentedon Dec 5, 2025
Oh, okay. No worries
Update Questionnaire population with sdc changes on immutability
LZRS commentedon Dec 10, 2025
@ajhmohammed The PR #3804 has been updated with a fix
@rkareko