Lag in survey

135
4
Jump to solution
03-04-2020 01:56 PM
SMa
by
New Contributor II

I have discovered a lag when entering an integer, which enables affects two repeated groups.  One of the repeats labeled "construction_b2" is the cause of the lag.  When I take repeat_count off from construction_b2 no lag occurs.  What can I do to rid of the lag because I still want it to have a repeat_count connected to integer question labeled "total2"?

0 Kudos
1 Solution

Accepted Solutions
DougBrowning
MVP Frequent Contributor

Well one your form is huge.  I thought mine were big.  I know you did not ask but it seems like it would be very hard for a user to follow.  Does it have to be all in 1?  Does it submit ok?  The attribute table must be very hard to read.  What have the users said about the size?  For me I broke my project into 9 forms to combat some of this. I launch them all from Collector.

Have you tried pages to break it up a bit?

With repeat_count is does not limit the number of repeats it actually preloads them all.  That is why it is taking a bit to spin them all up.  Just that one repeat is 400 lines with a ton of lists X how many repeat records.  It should be slow if it is that big.  I have one at like 300 lines and it takes 22 seconds to load on a android tablet.

Most of your lists are short except fn2a.  I do not see that one in the repeat but I may have missed it.  If it is try moving it, and maybe some others, to an external choices instead.  When I have lists of 5,000 it helps a ton since it does not have to load them right away.

Hope the helps.

View solution in original post

0 Kudos
4 Replies
DougBrowning
MVP Frequent Contributor

Well one your form is huge.  I thought mine were big.  I know you did not ask but it seems like it would be very hard for a user to follow.  Does it have to be all in 1?  Does it submit ok?  The attribute table must be very hard to read.  What have the users said about the size?  For me I broke my project into 9 forms to combat some of this. I launch them all from Collector.

Have you tried pages to break it up a bit?

With repeat_count is does not limit the number of repeats it actually preloads them all.  That is why it is taking a bit to spin them all up.  Just that one repeat is 400 lines with a ton of lists X how many repeat records.  It should be slow if it is that big.  I have one at like 300 lines and it takes 22 seconds to load on a android tablet.

Most of your lists are short except fn2a.  I do not see that one in the repeat but I may have missed it.  If it is try moving it, and maybe some others, to an external choices instead.  When I have lists of 5,000 it helps a ton since it does not have to load them right away.

Hope the helps.

View solution in original post

0 Kudos
SMa
by
New Contributor II

This is a first draft and will clean up after this first round.  I have broken it into pages and the lag still exists, but I probably will have to separate options from the group that's causing the lag, but still in a repeat so the behavior doesn't change in repeat_count.  Thanks!

0 Kudos
DougBrowning
MVP Frequent Contributor

One other idea is to hide some of it in a Relevant until it is needed.  Not sure it will help but maybe.

0 Kudos
SMa
by
New Contributor II

I have done that and a lot of where the lag is, is already in relevant.  Still a lag, but probably not as much as if they were all shown at once.  Thanks though.

0 Kudos