Slow repeating group

Hello there,

I was wondering if is there going to be an improvement of the repeating group showing data slow. Because we´ve to show more than 100 items and it´s really really slow that sometimes even breaks the app.

Can you us something about this @emmanuel

Thanks a lot.

We’re working on this.

Nice, I did not now it was related.

Thanks a lot.

Any news about this please?

It´s our main complaining issue from users.

Thanks a lot.

We’ve got a large repeating group with two medium sized repeating groups nested inside. We just pushed an update that changed how we queried the data, and our speed improved by at least 10x. How are you loading the data in your group? There might be some optimizations you can make, depending on your setup.

Only mentioning it because prior to our update, we lost a ton of users because of performance, and it turns out it was just cuz we weren’t making efficient data requests.

Hi,

We´re loading the data with a “do a search for …”

Is there any other way? Since we´re loading invoices that could be more than 1000 for each user.

Thanks a lot.

When I moved away from “do a search for,” that’s what caused my performance to jump up so significantly. I’m not sure what your comment about being more than 1000 for each user means? Last I heard, the limit to a list size was upped to 10,000, so if you’re concerned about that, maybe it’s not an issue anymore?

In my app, I have students and skills, and each student has a rating for each skill. Previously, I was doing this:

  • do a search for ratings where student = parent group’s student and skill = current cell’s skill

Now, I’m doing this:

  • Current cell’s student’s ratings:filtered (skill = parent group’s skill):first item

So, there is a field on the student called “Ratings,” and I’m specifically querying for that list of ratings. It’s the difference between saying, “Look through the entire universe and find me stuff that matches this constraint,” vs, “Look through this one student’s stuff and find me stuff that matches this constraint.” Much faster, for sure.

6 Likes

I think I understand that but I´ve users that already has about 300 invoices and in the user I don´t have a field called “invoices” which is a list of invoices.

That´s what you mean? To have a field on the user of the “invoices” so I can retrieve a list instead of making a “do a search for …” ?

Thanks a lot for your help @potentialthings

Bests.

I think that’s what I would do in your case, yes. Now, the challenge is going to be migrating the existing invoices to make it work with your existing data…interesting.

Yep, that´s really interesting. Hehe

I was doing filtered for a while, but @emmanuel had advised in other posts that do a search for would have the quickest results. Has something occurred that would change this guidance?

1 Like

I thought @emmanuel was saying that the “do a search for” would be slower? That’s what I’m basing my info off of, but in the real world, making the change away from that dramatically improved my performance. I wonder if maybe that’s just a happy coincidence? Hmm…

Now I am curious. Although that would be a major shift in my own app.

Also got me curious now as I’m currently building something that has a very similar feature. Definitely food for thought

I also thought that the do a search for was the quickest one. Now I don´t even know what to do.

Hi @josh, would you be able to comment on why the second scenario is quicker?

1 Like

I guess I’d say try things until you’re happy with the performance, which is a lame answer but also similar to regular software development. I guess for me, it feels like doing a search for would be intuitively slower because it’s going through the entire dataset available on your app, rather than starting at a smaller scope. The difference between looking for a fish in a kitchen sink vs looking for one in an ocean.

Then again, I’m not an engineer so I have no idea what I’m talking about 95% of the time :slight_smile:

3 Likes

I like that “Then again, I’m not an engineer so I have no idea what I’m talking about 95% of the time :slight_smile:

Me too! Haha. That´s the fun part.

:filter downloads all datasets to the client and hence is definitely slower

I have no idea why my experience is the opposite of this. Reading this explanations makes sense, but my real-world experience says otherwise.

Our teachers are reporting a difference of up to 3 minutes in loading time for the same data sets. The dataset in the example I shared is small, so the difference isn’t so drastic. Literally the only thing we changed was going from “do a search for” to a more focused search, shown in the images below.

Old Method

New Method

My Reaction