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.
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
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.
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.
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.
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 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. -
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.
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.