Good day,
I'm consulting on a CommCare project that has inherited some apps from a
previous implementer.
One of the forms runs very slowly:
- It is slow to load
- It is slow to transition between questions
- Text fields lag - it takes a second or two for each character to be
displayed after it is typed.
I suspect the culprit is the very large number of HiddenValue questions
(about 130 of them).
These are used to update counters on the parent case.
The calculations typically look something like this:
Question ID: new_counter_A
Calculate Condition: #case/parent/counter_A + #case/counter_A
Display Condition: #form/confirm_details_are_correct = 'yes'
This field is then written to parent/counter_A when the form is completed.
I am looking for ways to improve the form speed without changing the whole
app structure.
I know that for HiddenValue fields Default values are loaded once when the
form is opened, but the Calculate Condition is re-run each time a value in
the form is changed (if I understood correctly).
I'm guessing this is why the form is so slow.
Question: Does referencing #case properties in the Calculate condition
make the calculations significantly slower than only having #form fields?
If this is the case I could split the questions into 2 questions:
First, load the case properties once when the form opens:
Question ID: load_new_counter_A
Default Value: #case/parent/counter_A + #case/counter_A
Then, only reference the form field for the Calculate Condition:
Question ID: new_counter_A
Calculate Condition: #form/load_new_counter_A
Display Condition: #form/confirm_details_are_correct = 'yes'
Which might speed things up.
Any other comments or suggestions are welcome!
Thanks,
Andrew
Hi Andrew,
If it is the case that it the case reads which are slowing down the form,
moving the calculations into Default Values is a very good move.
The question of whether referencing case properties is slower than form
properties will depend on a significant number of factors, but generally
speaking if you are running the newest version of CommCare I would find it
somewhat surprising if referencing an individual case in this manner was
introducing a tremendous slowdown.
If due to the way the form is laid out, updating an individual question
somehow re-triggered all of the hidden values I could imagine that being
an issue, however, in which case that could be an effective change.
If all of the fields in the form depend on
#form/confirm_details_are_correct
One useful check would be to see whether ~every question in the form is
changing a display condition or calculation for that value, which would
result in the values re-triggering. If the conditional display of that
question is not vital it may improve the form performance significantly to
remove display conditions on that question.
-Clayton
···
On Mon, Aug 21, 2017 at 10:39 AM, Andrew Cawood wrote:
Good day,
I'm consulting on a CommCare project that has inherited some apps from a
previous implementer.
One of the forms runs very slowly:
- It is slow to load
- It is slow to transition between questions
- Text fields lag - it takes a second or two for each character to be
displayed after it is typed.
I suspect the culprit is the very large number of HiddenValue questions
(about 130 of them).
These are used to update counters on the parent case.
The calculations typically look something like this:
Question ID: new_counter_A
Calculate Condition: #case/parent/counter_A + #case/counter_A
Display Condition: #form/confirm_details_are_correct = 'yes'
This field is then written to parent/counter_A when the form is completed.
I am looking for ways to improve the form speed without changing the whole
app structure.
I know that for HiddenValue fields Default values are loaded once when the
form is opened, but the Calculate Condition is re-run each time a value in
the form is changed (if I understood correctly).
I'm guessing this is why the form is so slow.
Question: Does referencing #case properties in the Calculate condition
make the calculations significantly slower than only having #form fields?
If this is the case I could split the questions into 2 questions:
First, load the case properties once when the form opens:
Question ID: load_new_counter_A
Default Value: #case/parent/counter_A + #case/counter_A
Then, only reference the form field for the Calculate Condition:
Question ID: new_counter_A
Calculate Condition: #form/load_new_counter_A
Display Condition: #form/confirm_details_are_correct = 'yes'
Which might speed things up.
Any other comments or suggestions are welcome!
Thanks,
Andrew
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Clayton,
Thanks for the detailed response.
The display conditions are only dependent on case properties, not on
answers to form conditions, so I would not expect them to be re-calculated
all the time.
I'll attempt some changes and feedback if I'm able to see significant
improvements.
Thanks and regards,
Andrew
···
On 22 August 2017 at 22:28, Clayton Sims wrote:
Hi Andrew,
If it is the case that it the case reads which are slowing down the form,
moving the calculations into Default Values is a very good move.
The question of whether referencing case properties is slower than form
properties will depend on a significant number of factors, but generally
speaking if you are running the newest version of CommCare I would find it
somewhat surprising if referencing an individual case in this manner was
introducing a tremendous slowdown.
If due to the way the form is laid out, updating an individual question
somehow re-triggered all of the hidden values I could imagine that being
an issue, however, in which case that could be an effective change.
If all of the fields in the form depend on
#form/confirm_details_are_correct
One useful check would be to see whether ~every question in the form is
changing a display condition or calculation for that value, which would
result in the values re-triggering. If the conditional display of that
question is not vital it may improve the form performance significantly to
remove display conditions on that question.
-Clayton
On Mon, Aug 21, 2017 at 10:39 AM, Andrew Cawood acawood777@gmail.com wrote:
Good day,
I'm consulting on a CommCare project that has inherited some apps from a
previous implementer.
One of the forms runs very slowly:
- It is slow to load
- It is slow to transition between questions
- Text fields lag - it takes a second or two for each character to be
displayed after it is typed.
I suspect the culprit is the very large number of HiddenValue questions
(about 130 of them).
These are used to update counters on the parent case.
The calculations typically look something like this:
Question ID: new_counter_A
Calculate Condition: #case/parent/counter_A + #case/counter_A
Display Condition: #form/confirm_details_are_correct = 'yes'
This field is then written to parent/counter_A when the form is
completed.
I am looking for ways to improve the form speed without changing the
whole app structure.
I know that for HiddenValue fields Default values are loaded once when
the form is opened, but the Calculate Condition is re-run each time a value
in the form is changed (if I understood correctly).
I'm guessing this is why the form is so slow.
Question: Does referencing #case properties in the Calculate condition
make the calculations significantly slower than only having #form fields?
If this is the case I could split the questions into 2 questions:
First, load the case properties once when the form opens:
Question ID: load_new_counter_A
Default Value: #case/parent/counter_A + #case/counter_A
Then, only reference the form field for the Calculate Condition:
Question ID: new_counter_A
Calculate Condition: #form/load_new_counter_A
Display Condition: #form/confirm_details_are_correct = 'yes'
Which might speed things up.
Any other comments or suggestions are welcome!
Thanks,
Andrew
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "commcare-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/commcare-users/-YGzhzULRzU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.