android-fhir: Slow performance on large Questionnaire

Describe the bug A clear and concise description of what the bug is. When the SDC library tries to render a large Questionnaire (+75K lines of JSON).

It takes a long time to load and show the initial page the user can see. To the point of the app becoming not responding, sometimes
~2 second delays for simple action (next button, radios, checkboxes, tapping a keyboard)
3-5 second delay when loading a page w heavy calculation or tapping Start IPC option (which will open up many pages in the background, the next pages)

Component SDC library

To Reproduce Steps to reproduce the behavior:

Download the sample Questionnaire I’ve provided
Paste the downloaded sample Questionnaire into catalog app’s assets folder
Change this line to ‘ipc-session-1.json’ https://github.com/google/android-fhir/blob/master/catalog/src/main/java/com/google/android/fhir/catalog/LayoutListViewModel.kt#L41
Run catalog app
Tap ‘Layouts’ at the bottom app bar
Tap ‘Default’ on the screen
Now wait
If the app shows not responding, tap wait
Once it’s rendered, try to interact with the questionnaire, it should have the delays as I mentioned

Expected behavior A clear and concise description of what you expected to happen.

Load the Questionnaire faster, and not to the point of the device went not responding
No delays when performing simple action (next button, radios, checkboxes, tapping a keyboard)
Less delays for heavy calculation or tapping Start IPC option (which will open up many pages in the background, the next pages)

Videos Demo of the +75K Questionnaire:

device-2023-07-12-155717.webm

Demo of normal sized Questionnaire (In-comparison):

device-2023-07-12-160004.webm

Smartphone (please complete the following information):

Device: Pixel 4 emulator with 3GB of RAM
Android version: [e.g. Settings -> About phone -> Android version]
Build number: [e.g. Settings -> About phone -> Build number]
Version [e.g. 22]

Additional context

The sample Questionnaire https://drive.google.com/file/d/1IJsrTvZ5StjJJM_UinsQcQE91j_qE-AZ/view?usp=sharing

Would you like to work on the issue? N/A

About this issue

Original URL
State: open
Created a year ago
Reactions: 1
Comments: 20 (6 by maintainers)

Most upvoted comments

discussed today at the dev call with @FikriMilano, @omarismail94, @santosh-pingle and others. we’ll need to do a little more profiling and testing. But here’re some initial thoughts:

with a large questionnaire, it’s very likely the deserialization takes a long time. at the moment the sdc library’s questionnaire fragment takes the questionnaire as a json string or as a file path, so the deserialization will have to happen when the fragment is intialized, which could be a problem. we can look into allowing the fragment to take a questionnaire in memory, which will allow pre-deserialization to happen if the app wishes to do so.
we can look into optimize calculations using some simple heuristics - for example limit calculations to the current page. we don’t do any optimization yet to ensure correctness. for example, you may have a variable expression in a different page of the questionnaire that depends on one question in the current page, but another question in the current page might depend on that variable expression. as a result, we calculate everything in the questionnaire when things change. but maybe we don’t need to do this.
another optimization we can do is, to create a proper dependency graph between expressions and questions, so that we can optimally update things as needed, whilst maintaining correctness.

jingtang10 on Jul 13, 2023

Yeah definitely, thanks again @omarismail94 😄

We still need improvement on clicking around.

Still, it’s a massive improvement for loading. 😄

FikriMilano on Jul 20, 2023

@FikriMilano The configurable_care branch does not have a solution for this, rather just another reason to have this feature: fragment accepting a questionnaire in memory.

MJ1998 on Jul 20, 2023