Performance Improvements required
Completed
When a simple form (no subforms) with say 20 attributes has data uploaded through csv with 200 records approx the resulting performance when navigating from the table to records and back us too slow making it not efficient in the field. Option lists are small as well
The situation gets exponentially worse when more records are added. For example 800 records uploaded make the form completely unusable. This is before photos are added as well.
Please improve the performance of the client.
-
Official comment
This has been resolved as of August 2015. Big thanks to everyone who helped with examples!
Comment actions -
This is a huge problem:
- Condition values in option lists slow the performance of the forms way down. If we have 10 data collectors who should each see a different set of 25 options in a list, it takes several seconds to display the form just because of that option list.
- Ideally, users should be able to refer to a record of their previous notes. As Antoine mentioned, having even a couple hundred records saved slows performance to a crawl.
- It would be great to be able to sort those records so that the most recent records are on top. However, adding a simple sort to the record view makes the display of the record list FOUR TIMES SLOWER. With 800 records, that means the user has to wait almost a minute every single time s/he goes to the record screen. -
Hi All, the problem is a tricky one. The record view will be challenged when there are hundreds of records due to the dynamic displaying / sorting of data on this view. We are spending time to see what performance gains can be made. As we learn, more we will be sure to let you know.
@ Antoine: Can you elaborate on what timeframe 800 records covers (1 day, 1 week, etc..)?
@ Jamie: Are you using the OPTIONLIST_SEGMENTED_LIST flag in your implementation? That significantly improves the speed of conditional option lists.
-
Thanks, Tony! It's good to know that setting up segmented option lists improves performance. I can't find anything on Google about setting an OPTIONLIST SEGMENTED LIST or OPTIONLIST_SEGMENTED_LIST flag -- is that an undocumented feature in the API somewhere?
One issue I have is that the elements in my option list need to be in a specific order, and so there are not necessarily easy divisions -- the option 1 might be limited to one user, option 2 to a different one, option 3 to the first user and a third user, option 4 to just the first user again, etc.
Does the OPTIONLIST_SEGMENTED_LIST flag work even if identical options are not immediately adjacent? If not, it would be great if you could add that in -- i.e., look through the list of condition statements in the option list and find all duplicates, then only evaluate each duplicate once, applying that same truth value to the rest of the identical copies. You could have a separate flag if you're worried about backward compatibility with some weird edge case.
-
Hi Jamie, please have a look at this article for more information on using the SEGMENTED LIST flag.
https://iformbuilder.zendesk.com/hc/en-us/articles/201699350?
This idea requires that the segments are single condition statements tied back to a previous option list selection (index based). This allows us to perform some indexing on the option list data, so the small processor on the mobile device isn't overworked trying to chunk through all the information and statements real time.
I am not sure if this applies to your specific implementation, but have a look and hopefully it can help.
-
Thanks again for your help, Tony -- unfortunately, the OPTIONLISTTYPE_SEGMENTED_LIST flag doesn't work with my situation. If I have condition statements that give a user permission to see the first, second, fourth, and fifth options in a list, when that flag is set it will only show the first and second options to that user but not the fourth and fifth (i.e. the third option overrides all the ones that come after it).
From a programmer's perspective, could you optimize option lists by going through the list of condition statements and creating a key-value list? One that links each unique condition statement to an array of all the lines that use that exact same condition statement?
That way, if I have 40 lines (scattered throughout my pick list) that all have the condition [ user == "jamie" || user=="admin" ], that condition statement would only have to be parsed once. Then it could be applied to each of those 40 lines, no matter where in the list they occur. That would be somewhere approaching 40x faster than having to individually parse that same condition forty times.
Given what I've seen of segmented lists, it seems that this method would still be backward compatible with them. It would just be a lot more flexible for cases where a regular segmented list wouldn't work because some options in the list have overlapping conditions.
-
This continues to be a major issue for us. The use case where impacted the most is when we need to upload a csv of existing records for update in the field. I have an example of a simple form with no subforms and just 12 elements with only one option list of 5 values and a displayfield of 5 elements to help select the right record. Loading 300 records which is typical renders this form too slow and our users are complaining.
I can work around this by splitting the records over copies of the forms but this is not slways intuitive or effective and causes maintenance overheads.
I would really like this looked at as a priority as it will impact my organisations use of the product in the future and may require us to consider alternative solutions for this use case.
-
Hi Antoine, as I mentioned before, we are digging in, but there is no quick fix for this that doesn't cary heavy impact.
One thing you can do which will help dramatically is reduce the number of columns you are trying to display on the device from 5 down to 1. You can still get all the information you want that is pre-populated visible by concatenating the data into a hidden field.
Another option is to go with a private client, and we can tune the code for your use case (there will be trade-offs for speed versus flexibility).
Have a look at reducing the number of columns you are showing, and see if that has an acceptable improvement for you, otherwise please drop me an e-mail regarding private client option.
Cheers,
Tony
Please sign in to leave a comment.
Comments
8 comments