Speed of screen updates from database

chris.charette241 · 2020-12-11T17:34:58.955Z

I am pulling data from the Bubble database to the screen via a Repeating Group. It’s only pulling 6 bits of data each record but there can be hundreds of rows. It’s taking minutes to redraw the screen but I’ve seen instances in other web applications where this same sort and amount of data is presented immediately. There is a video link below that shows that for 570 rows of data it takes nearly 3 minutes (the video is sped up to 200%).

I’m using a RG with 6 text fields. The RG does the search, and the text fields use the results of that search:

image695×479 25.7 KB

Is there a better way to present upwards of 1,000 rows of data without having to wait for so long?
Bubble Loading Speed

cmarchan · 2020-12-13T03:45:22.306Z

Please share how the property and rent objects are related and their field structure. If there are other datatypes related please share.

chris.charette241 · 2020-12-14T17:13:21.851Z

The field structure of these databases were designed to facilitate getting things up and running so they could use some refining but there’s basically two tables involved on this page. There’s a Property table that has some 71 fields (47 shown here, the 24 others to be removed) and there’s a Rent Roll table that has 20 fields. The relationship between the Property and Rent Roll tables are the Name and Property Name fields.

The page itself displays Property data (Name, Address, etc.) and the search of the Rent Roll table for displaying the data discussed above keys off the Name field.

The Property table only has 20 records but the Rent Roll table has nearly 2,800. The Property table also has about 20 fields that are images if that helps to understand the possible impact, though only one is used on this page.

image527×967 33.3 KB

ed727 · 2020-12-14T18:36:01.029Z

How data heavy is your Rent Roll datatype? Does it contain images or lists? From what I’ve read, a heavy datatype will take longer to load since Bubble is loading more onto the page from that datatype than is displayed. Also I’ve read that heavy datatypes take longer to search.

If your datatype is heavy, you could try a few things:

Getting rid of long lists
Using privacy settings to limit the amount of data Bubble loads onto the page
Splitting your datatype. Have a bare-bones entry for what you’re trying to search and display in the list, and then put all the heavier stuff into a connected datatype that is used for details display

Some great insights in this post on structure:

Alternative approach to the Bubble’s recent tutorials for list of things Tips

Hello everybody, I’ve taken a look at some tutorials from the following topic: In short, I think that these tutorials contain some crucial mistakes. Regarding How To Build A Pinterest Clone Without Code Configure your database User [image] We’re facing this mistake on many apps. That’s a wrong approach since it negatively affects performance and speed. Let me explain why I do think that this is wrong. The Bubble’s unique id for each thing looks like the next one: 1583401182457x36677842…

chris.charette241 · 2020-12-14T20:28:52.216Z

There are no lists are in the Rent Roll
I didn’t set any privacy settings, I didn’t want to restrict the user from seeing the entire rent roll.
The Rent Roll itself only contains text, numbers, dates and one yes/no field, 20 in total. It’s not necessarily bare-bones but I didn’t consider that using two tables to store all this related data made sense.

The Rent Roll does have 3 fields that could be calculated but I didn’t know if calculating them as they enter the database or as I need them would be best. Given that the current presentation speed is slow, I’m inclined to calculate it in the database rather than add any extra time during the display process. In the example that I recorded I don’t even access those particular fields.

ed727 · 2020-12-14T21:18:21.608Z

You could do a test where you use privacy settings to remove those calculated fields from what Bubble can load on the page, and see if that makes a difference. That would tell you whether or not Bubble was trying to calculate the field even though you weren’t asking for it on the page.

Generally though, if those calculations are specific to the entry and not to the user or search, I’d think you’d want to go ahead and calculate them and store them as values. Much more efficient to calculate them once vs. every time they are loaded.

I wasn’t able to view the video you reference, but assume that it’s simple stuff as you mention, with nothing nested (where each row would need to do a search or pull in data from another datatype).

chris.charette241 · 2020-12-15T01:02:38.229Z

My apologies…the fields I referenced as calculated were calculated before going into the database and are not calculated while updating the screen. While building the site, I needed these as reference points so I added fields that I would later calculate live but this is not one of those situations. The only data that I’m presenting now, and which I’m showing as slowly appearing on screen, are 6 static fields of data…there’s just a few hundred of them.

ed727 · 2020-12-15T03:41:03.008Z

I wasn’t able to access the video, so I don’t have a sense of what’s being shown and how fast/slow it’s loading.

With speed, I just test different things to see what may be affecting it. In your case…

Your search is simple, so that’s probably not slowing it down (however, read the Bubble documentation about indexing searches that speed them up over time)
You don’t have any nested info you are pulling into the results – it’s all from the rent roll datatype. Also no calculated fields. So you’re good there.

One thing I would try is to go into your privacy settings and unclick anything you aren’t showing on that specific page for both the property and the rent roll. It’s an easy test to do, and would indicate whether stuff that you aren’t showing on the page is slowing the load.

There’s also the school of thought that says to avoid the search altogether and have the rent roll as a list within the property field, so that the RG would just be the Property’s Rent Roll. I personally dislike that approach because it goes against good database design principles, and it will make your property datatype records very data heavy. But some people do it in order to pick up a speed gain. You will see active debates on this topic in the link I referenced, and also here: Leaving Bubble for more traditional development?

chris.charette241 · 2021-01-22T21:22:49.840Z

I’m still trying to address the onscreen display of these 569 rows of data from a table. It takes over 3 minutes to display and the data itself is only 79kb if placed into a text file, and the entire table itself, with 2700 rows is just 700k as a csv file. It should not take 3 minutes to pump this data to the screen.

In the example in this video, I’m using a repeating group and showing 6 fields of data. I have to constantly scroll up and down just to get Bubble to put more data on the screen. Otherwise, it just stops.

I have read through many of the suggestions found, including those referenced above. I believe that I’m following the best of these suggestions. What I’m doing is nothing more than presenting static data from the table.

If nothing else, how can I get Bubble to display the entire set of data without having to scroll up and down to get Bubble to respond with its next batch of data, presumably only about 5k of data each time.
Bubble loading speed

ed727 · 2021-01-23T14:40:24.088Z

That does look slow. If you could screenshot or describe your datatype structure and also the search you are using, that will allow people to give specific suggestions.

Also in what country are you located? Sometimes the speed seems to be related to geography.

chris.charette241 · 2021-01-25T15:03:29.246Z

Thank you…I’m in the US, east coast, really fast internet averaging over 700Mbps up and down.

The RG search is configured as such:

…and the cell is configured with 6 text fields configured like:

…with the grey field just displaying the cell index.

The Rent Roll data type has 19 fields and the table itself has just under 3,000 rows:

image334×879 27.2 KB

ed727 · 2021-01-25T16:08:54.749Z

Looks fairly straightforward. The only thing I saw is for the PropertyID I would have connected that to the property datatype to give you more flexibility down the road, but that shouldn’t impact the search speed or load performance.

To test whether the slowness is due to the search or the display, you could duplicate the page and remove the Current Page Property ID search constraint, and put an items until 569 constraint on the Data source. That would tell you if the slowness is due to the search or due to the time it takes Bubble to load the page, but I suspect that it would show you it’s the latter.

So your options probably are:

Split the Rent Roll datatype into what’s shown and a connected additional details datatype, and see if that improves things
Instead of showing a full list, use a scrolling RG or use pagination

Out of the above personally would go with #2. #1 would be a pain do to and it’s unsure whether it would lead to any improvement. (To test this you could dupe your app, delete a bunch of fields from the Rent Roll datatype and see how it runs). The answer unfortunately may be that Bubble just doesn’t load RGs on the page very fast, and the RG is very data heavy. With a shorter list this doesn’t matter, but in a long list the slowness shows and the browser bogs down.

Also, regarding #2, web designers generally stay away from long lists to keep the app pages light and fast, and use scrolling RGs and pagination instead. This is what I’ve done in my app, so it seems fast to me even though it may be loading at the same speed as yours.

Also, if you’re on a paid plan, I’d recommend running this by Bubble support. They’re helpful and may have some insights for you.