the database has 75 data fields.
and a basic load on a repeating group is 23.66 seconds to load.
there are more than 2000 records yet and increasing daily… but the repeating group is set to ext. vertical.
how can we cut down the load time?
PS. I tried capacity boost… but no measurable difference noted.
2000 records times 75 fields is 15,000 fields of data being loaded into the RG…
Do you need all that data in the RG? (what is the purpose of the RG?)
Maybe consider splitting the datatype into a ‘light’ version and a ‘heavy’ version (i.e. have the ‘light’ datatype just for the purpose of displaying the items in the RG, with just the fields that are relevant for the RG, and have a separate ‘heavy’ version for displaying all the data when required).
How many fields do you show in the RG at any one time?
10 for avg user and 16 for admins
75 fields are on backend… on display they are max 16 fields…
Does the setting where RG loads fields on scrolling down makes difference ?
Adam’s right. You should make another table with only max 16 fields. if you could restrict the fields returned you’d be in a lot better shape but at this point it’s not possible.
Essentially every time you load it even though you’re only requiring 16 fields all 75 are brought over to the front end by the back and because bubble doesn’t know how to do it differently yet. This is very very likely the reasoning for your high load times.
Great … Getting my answers… thanks allot.
Question 1.
If I make a LightDB of only 10 fields that contains a “field” HeavyDB in it to create a relation is that good.
Question 2.
As of today, total entries into HeavyDB are around 4500… and on monthly basis 1000 more are expected…
My current view setting for Repeating Group is Vertical Ext. as in it displays more item as you scroll down…
Will adding pagination help with load time…
Also if your filtering is getting kicked to the client side, then Bubble is downloading thousands of entries to find enough matches to fill the visible part of the RG. That can seriously slow down the process, especially if the entries are data heavy (as yours are), since every field in an entry is downloaded to the browser.
Scrolling RGs are supposed to be the most efficient (bubble only downloads enough to fill the visible slots, plus a few more). I don’t think pagination will help, but you can experiment to see the impact.
PS: the network tab in Google’s dev tools is invaluable for stuff like this – shows you exactly where the slowdowns are happening and what’s being downloaded to the page.
