Improving Repeating Group Loading Performance

The very slow loading of a repeating group with over 100 records has been discussed before. Improvements on repeating group performance

Apparently, this is a known limitation.

However, I found it interesting that the warning icon in the bottom right of the Workflow Debugger did not suggest buying more capacity.

Is this because more capacity will not help load the repeating group faster, or is the loading speed of the repeating group not being measured?

@ryanck
@romanmg
@emmanuel

What expression did you use for the repeating group’s data source? Database structure has a massive effect on search speeds. Also, what display type (full list, ext. vertical scroll, etc.) did you set for the repeating group? These things have an impact on a repeating group’s loading speed just as much as the number of items being displayed.

Daniel

Search for, merged with another search for.

full list, which is needed

this doesn´t solve your problem from a loading speed perspective, but if you show a loading screen while the RG is loading, you can improve the user experience

2 Likes

I would surmise the issue is not necessarily the repeating group but more the fact that you’re doing a search merged with a 2nd search and then attempting to display “full list”… Try applying the same rationale and simply displaying the text field and see how quickly you get the results back… In many cases when things are slow we need to rethink from the ground floor up how we structure stuff in order to accommodate the requirement… And sure this very good reason you’re attempting to display full list but as I’m sure you know this is not ideal. Pagination is always a good option if your user case allows

dbevan You mention a few considerations. What is the best choice for each? We have 125k records with 8 fields per record, so we want to minimize page load time, the load on the server, etc. Thanks!

The less data you have to display on page load, the better. There should be no need to display 125k things at once so figure out ways to deliver only what users need to see.

4 Likes

the issue doesnt begin with 125k things, it begins with over 100 or so, that’s the issue here.

2 common methods you can try:

  • Use a vertical scroll repeating group.
  • Implement pagination.

will pagination actually make it speed up?, why would vertical scroll change anything?

  • Bump, this is a SERIOUS issue that needs fixing

How much data are you trying to display, and is it a simple 1 Data Type search or is it multiple data type searches in one?

its a simple data search for dream journals that have the same username as user, as the user adds more and more dream entries the loading becomes real slow. And Im not even talking about more than probably 50 entries before it gets real real slow.

Note that if in your RG you are only showing basic stuff on an entry like author and date, everything from that entry is being downloaded to the browser. So if each entry contains a journal entry, and those entries are fairly long, that could be the issue. Data heavy entries take longer to load, and as the browser memory fills up, on-page performance degrades.

Without seeing your data structure and RG searching, it’s hard to say with certainty that’s the culprit. But it could be. If it is, then your solution is to split out those long journal entries into a separate datatype, and you tie them 1:1 to a datatype that contains the other stuff (name, date) that you can search and show in a RG. Then if someone clicks on one of those entries, it can pull up the related datatype showing the journal entry.

1 Like

I see, there are lots of fields in my data entry, so you are suggesting that I split these up and dont have so many fields on one data type? Hopefully i’ve understood you.

Correct and these articles describe the why and the how:

thankyou! Will take a look

I’m saying that data heavy fields (like long text entries, or long lists) might be the problem. But there are lots of things that can cause RGs to be slow. So the first step is to isolate and confirm what is causing the problem. Then you’ll know what you need to fix.

Here is a link to a screen recording showing what happens when this group opens - Imgur: The magic of the Internet

Here is a photo of whats being loaded in this group, since these are dream journal entries the content can indeed get quite lengthy, sometimes a few thousand words, there is currently no pagination. -
fefefefeewww

Photo of all the data types (the content is where most of the text will be), keep in mind this is during development so lots of fields are empty.

Hopefully this helps someone, that can help me lol. (still new to this bubble stuff)

It’d be much better to instead create a list of “dream journals” on the User data type, so instead of searching for all “dream journals” and filtering just the current user’s, which could lead to slower loading speeds, it instead loads the journals just created by the user.

Ah, so when I search for dream journals with only the users username, its actually searching every dream journals on the site? hopefully I understand.