Form saving delay from calculations


My organisation is transitioning over to ODK for the purpose of collecting ground cover data (e.g. vegetation) at selected sites to monitor rangeland properties.
I have designed a series of forms for this purpose and our field crews have been testing them recently.

One of our forms (see attached) is used to collect ground data from 3 transects at a given site. The form has 100 repeats (per transect), which are nested within 3 repeats, making a total of 300 samples. At each sample point, we record the ground cover type (e.g. bare ground, dead vegetation matter, grasses, forbs). In order to generate running totals of ground cover while the field crews are collecting data, I have put calculations within the repeats using 'if' statements and assigning 1 and 0 to each cover type. From my testing, I found that the form will finalize in 1-2 seconds when these values are assigned in that manner, but the form save time increases to over a minute when I add calculations to find the total of each cover type, using sum. Saving time increases by another 20-30 seconds when I add in additional calculations (e.g. to calculate proportion of different vegetation types).

Would these calculations cause an appreciable enough increase in memory usage in ODK that would account for the increased saving time? I'm thinking it may be due to the number of repeats, but the calculations are fairly simple and not overly numerous. I would appreciate the opportunity for other sets of eyes to have a look at the form and see if there is something in the way I have written the code that may be affecting the save time. I haven't been able to find a way yet to simplify the code.

ODK Collect v1.22.4
Samsung S2 tablets
Android v7.0

Transect_form.xlsx (18.0 KB)

1 Like

After a quick look, you could probably save a few cycles using numeric codes for your select response values instead of strings; a numeric compare of if(${GROUND}=42, 1, 0) is going to be a bit quicker than the string comparison of if(${GROUND}='green_perennial_forb', 1, 0)

Also, I note than in your final calculations that you are computing a series of 5 intermediate results (for PG_SUM, AG_SUM,... ). If they're all working towards 5 single results you could probably consolidate some of them into (5) longer caculations; eg

PG_SUM_PROP_ROUND = round(coalesce(${PG_SUM} div ${VEG_SUM}*100, 0),0)

hopefully you get the idea.

Hi Xiphware,

Sorry for the delay in responding. I've had my head down working through your suggestions and other ideas to optimise the form.

Well I'm very happy to report that I've had success - the entire form saves in just over 30 seconds, as opposed to the original 1 min 40. I removed some of the intermediate calculations and integrated them into longer ones. The original reason for having all those intermediate calculations was that the results were used to show the user a running total of percentages of vegetation species while they were entered (e.g. what % was remaining).

The most significant change I made was removing the nested repeats and just having three successive repeats of 100. It seems that nested repeats were causing the app to cycle more and work harder.

Thanks for your help with this, I appreciate it.