Just a general question about app performance.
Could the number of decimal places used in a lookup table have the capacity to noticeably slow down an app?
We have about 5 lookup tables each with roughly 200 rows over 5 columns, being used in one form. What I've noticed is that once we dropped down to 1 decimal point from 4 decimals things got quicker in the responsiveness of the device and webapp. It seems self evident but just wanted to check, maybe make a note of it on the lookups help page?
Hi - Thanks for reaching out. That's actually quite surprising to me.
When you say that you dropped down from 4 to 1 decimal, do you mean in the uploaded table, or do you mean in the accuracy of the filtering and processing within the form?
And when you say that the form is quicker and more responsive, I assume you mean both to load (menu click to seeing the form) as well as to respond when individual questions are answered?
Depending on your lookup table structure, it could be the case that 4 decimal points of data are significantly increasing the raw size of the payload itself, but with the overhead of the rest of the form data I'm still surprised to hear that it is so significant.
Yes we dropped the decimals in the uploaded tables. Ja it was a bit sticky in both the form opening and question progression.
Lookup structure is a fairly generic weight for age, height for age, height for weight, BMI, each calculated from -4SD to +4SD.
I was also surprised about the performance shift. The app is fairly big though, 35 forms with a case load of approx 50k, could that account for some lag within a form though?
@Toby and @Clayton_Sims : We did an internal analysis of the impact of size of each column value on loading of the form as well as form's performance while user navigates through it.
Here is an analysis of a single lookup table in a form which was observed for combination of size of each column (i.e. incremental number of characters in its string) and different sizes of lookup-table (w.r.t vertical scaling , i.e. increasing the number of rows of the lookup table) :
Lookup table loading has a very minute impact on size of each cell of table
Lookup table loading is solely depend on the size/scale/number of rows of the table
Form loading is independent of size of lookup table and size of each cell of lookup table
Lookup table loads way faster in if we use combobox as Appearance Attribute.
Impact of number of questions containing lookup tables with fix scale of each lookup table (i.e. fixed number of rows)
Decimal Places vs Number Lookup tables of 1000 rows each
3 places
4 places
5 places
6 places
7 places
8 places
9 places
4 lookup tables
21.14s
21.2s
21.5s
21.5s
21.5s
21.5s
21.5s
3 lookup tables
15.80s
15.82s
15.82s
15.82s
15.84s
15.90s
15.90s
2 lookup tables
10.1s
10.1s
10.2s
10.2s
10.24s
10.28s
10.28s
Note: The time mentioned in each columns is the total time taken to navigate through all the lookup tables
If you see the amount of time required to load each lookup table in a form, it comes out to be around 5 sec per lookup table with 1000 rows.
Conclusion :
Form loading is independent of size of lookup table and size of each cell of lookup table and number of lookup table in each form
When the scale is fixed, the lookup table will take same amount of time to load on the form and that time is independent of number of lookup tables present in the form .
Using combobox will improve the performance because using combobox as appearance attribute will remove the dependency of performance of lookup table on scale as well as total number of lookup tables used in a form.
Form performance is independent of lookup table’s size of data column.
Overall conclusion is that :
Number of rows in a lookup table plays a major role in deciding the form's performance while user navigates through it
Perfomace of form loading as well as form navigation was independent of size of data in each column of the table