A reflexion on question dependencies and display condition computation

Users
1

Hey,

The example is as follows:

  1. A label is placed alone inside a group
  2. That label will be displayed, conditionally, but alone on a page
  3. The label has a display condition that performs a casedb search + count operation to check for uniqueness of a case property called episode_code
  4. The casedb has a lot of records so the search ends up being a very slow operation for the hardware we're using.

image
image710×176 9.61 KB

As a consequence the application is super slow. Each time a digit is typed on the episode_code question, the application freezes for several seconds.

After some testing I came to the conclusion and verified that the display condition of the label was recomputed each time the episode_code changed even if the label in question was not part of the current application page.

I am thinking that in this situation, the application wouldn't need to compute the label's display condition until the page that it is on is displayed to the user. The benefit is that the slowness would only be experienced once by the user during the page transition, not each time a dependent question of that display condition is changed.

In our specific example the display condition relies on the value of a second question (multiple choice) so I was able to implement a workaround for this by testing that the second question was answered. But I am not sure I'd have a workaround if the label's display condition was only dependent on episode_code.

image
image599×171 9.84 KB

Curious how others deal with this situation, any other workaround.

Cheers,

G.

2

here are some tips for performance:

1- for your casedb queries, try to cascade your filters so that you are using indexed fields "case type, status, and a couple of others", and then cascade your filters so that they return the largest set first from left to right. so, status, type, perhaps owner, then go with the case properties that follow that logic cause it yields N > A > B > C....n/1/0
2- question lists. innocuous little things that can come in very handy in my experience. I believe that if you place those taxing calculations in a question list on that page, it will likely not fire the calculations until your question list is reached. but, this is based on a few years ago.
3- default condition. there's a trade off between putting your calcs in the calculate part, vs the default part. the default part fires only once on load. the calc part fires each time something changes. so what can you do? try fiddling with the depend() function. it is designed for this situation.
4- case load. try to make it so that the cases that load to the casedb are only the relevant cases for that user using org structure or case sharing groups. this can dramatically affect performance.
5- smaller case types. this can also affect performance. smaller here means "has less properties". it really only shows up most when you cases have upwards of 100 properties i think.
6- the nuke option: have a built in condition around your heavy calcs that checks if a certain question has been answered ,and have that question say something like "do you want to display results?". I have had to use this a long time ago and it was very effective at improving the user experience using the other parts of the form.

using all the above in conjunction will yield the highest performance you can dream of on a commcare app. for now :slight_smile: