CHT Android Super Slow on Form Load and Next Button

Technical Support
1

Hello Team,
We have more than 1 form on our CHT 3.15.
Both forms are considerably faster on browser but much more slower on CHT Android thus resulting to huge inconveniences in the field. After our tests we have noted that it takes 30secs to have a form load on field tablets. All our tablets have all the recommended specifications & model.
Has anyone encountered this issue?
What options do we have to relieve the frustrations from our field teams.
Thanks,
Job

2

Hi @Job_Isabai

When you say in browser do you mean a desktop browser or a browser on the same device that runs CHT Android?

Could you please share some details about your form? Is it a particularly large form? Many pages? Many repeats?

Thanks!

3

Hi @diana,
I meant Desktop Browser.
I compared the behavior in both apk and browser on tablets and to turned out to be similar.
Thanks,
Job

4

Hi @Job_Isabai ,

@antony was able to provide @diana and me with copy of your form. From there I was able to do some testing as well as reproduce your problem. Here’s some notes on the larger ped form:

  • it is 137kb in .xlsx format and 1.1mb in .xml format
  • it has over 800 rows in the .xlsx with no repeats (repeat_count)
  • it has over 200 calculation rows at the top
  • on a faster Ubuntu Laptop in Firefox the form loaded in <10 seconds and was responsive when using, not taking a noticeable amount of time between pages to load.
  • on a low end phone, but one that meets our requirements (Galaxy A01 Core), the form took almost 2 minutes to load and sometimes would take well over 10 seconds between pages to load, at worst taking almost 20 seconds between pages.

Here’s some possible paths forward:

  1. Remove any unused parts of the form. I mention this because while I for sure didn’t do exhaustive testing, I was able to test and complete the form in ~5-8 pages, which felt like maybe there might be sections that are unused.
  2. Break the form up so it is smaller, and more responsive forms. You would have to chain them together with tasks that get created and the CHW would have to be trained to know what to do.
  3. Make no changes and train CHWs to work around the slow form. While not ideal, if you’re not able to break up the form or optimize it, this has been a work around we’ve seen other deployments use.

Side note - I tested successfully in CHT 3.15.0, however I also tested in CHT 4.1.0 and noted it has a minor issue that I believe @jkuester can comment on!

2 Likes
5

Just to add to what @mrjones said, we did also test the form in CHT 4.x (since there was a lot of under-the-hood changes from 3.x when it comes to these ODK forms). The first thing we ran into was an error trying to open the form that ended up being caused by a couple of typos in the existing form. Two of the note fields had invalid HTML (mismatched tags). This will cause errors when trying to load the form in CHT 4.x. (@Job_Isabai I will dm you the names of the fields!)

Also regarding CHT 4.x, I did a very unscientific test for the loading times for the form comparing 3.15.0 to 4.x. The times I recorded were very consistent and showed that on 4.x the form loaded ~37% faster than on 3.15.0. This was just a quick evaluation using the browser on my laptop, so no guarantee of actual performance in the field.

1 Like
6

Hello @jkuester & @mrjones,
Thank you very much for the prompt reply.
Yes indeed the form is quite heavy as it is a clinical algorithm which comes in two segments, diagnosis and treatment. In each segment there are calculations and conditions involved.
We will review your recommendation and apply quick fixes whenever possible. Feel free to share more insights as we proceed.
@magp18 I would like to bring you in on this.
Thanks,
Job

1 Like
7

Hello @mrjones ,
You mentioned that:
" on a low end phone, but one that meets our requirements, the form took almost 2 minutes to load and sometimes would take well over 10 seconds between pages to load, at worst taking almost 20 seconds between pages."
In regards to the above comment, what would be the minimum (size of form, number of rows and number of pages) that is required to have better user experience on low specs device?
Your answer will be essential in helping us streamline the flow or even split it into much smaller responsive form.
Thanks,
Job

8

Is there a way to migrate an existing system version 3.15 to 4.x without losing data?

EDIT: Also, what is more performant, having less calculates but huge expressions in their calculation OR having more calculates with smaller expressions in them?

9

Is there a way to migrate an existing system version 3.15 to 4.x without losing data?

Absolutely! There should be no data data loss when upgrading to 4.x. The migration does require some manual steps documented here:

what is more performant, having less calculates but huge expressions in their calculation OR having more calculates with smaller expressions in them?

I do not have any hard numbers here and it is probably very dependent on your exact form and the devices it is running on. An a/b test would be the best way to get real performance data.

That being said, my personal expectation is that less calculations and larger expressions would be slightly more performant. Reevaluating a calcuate in Enketo causes a cascade where other other dependent expressions are also evalutated (which, in turn, causes more cascades). At the end of the day all the same expressions are being evaluated, but you would reduce some of the Enketo overhead by minimizing the number of separate expressions which can cascade…

(In general, though, I DO NOT recommend trying to prematurely optimize form performance by creating huge expressions. Large expressions are bug-prone and are hard to read/maintain. I prefer to focus on readability when creating a form and only would look to optimize for performance if it actually becomes an issue (as is the case in this thread).)

10

@Job_Isabai - Unfortunately we don’t have exact numbers here. @jkuester has some good ideas above, but generally “smaller is faster” is a good rule. When you take into account the speed of your devices and how much you can train your CHWs to expect slow downs, hopefully you’ll be able to increase the performance enough by trial and error. Sorry we don’t have a better answer here! (FYI - internally we’re considering if the CHT Test Harness could be use to iteratively test a form for performance improvements).

1 Like
11

Hi all! I’ve just posted about two Feature Releases which will hopefully improve the performance for complex forms like the ones being discussed here.

1 Like
12

Hi again! I’ve posted on the other thread some metrics about how much faster the FRs are and wanted to be sure folks following this thread knew about the update.

1 Like