Hi, I am curious as to whether as more rows are added to my app if that will decrease performance. One of the screens in my app already takes around 30 seconds to load as it is basically a big analysis screen of lots of data in the app. I am just wondering if this time to load will increase over time or not?
Thank you that tools helped a lot however I’m wondering if there is a way to improve the performance of a specific table, basically it is a range of dates that eventually will span years and years and it shows all the data for each date alongside it, I want to only load the rows in the specific time range set such as last 28 days or 90 days so that it doesn’t take ages to load the entire table unnecessarily.
Hope that makes sense
I’ve never had to do this, so I’m not speaking from experience.
An idea would be to store the mountain of data in a Glide Big Table, or even just a Glide Table, and the purpose of this data would only be to store all of it.
And then you could create a separate table just to display the last 28 or 90 days in a report or dashboard, and you would pull the data from the previous table, presumably via a relation.
Dates don’t work well with relations, so you would need to convert dates in both tables into integers for the relation.
I think that could be an approach.
The more data needs to be downloaded to your screen or computed on your device, the longer it will take for it to display.
Therefore, the more images you have in the table (subject to download) and the more computed columns (subject to computation on your device), the longer it might take.
A lot of the data is displayed for each day in a table as a red or green and then the details screen shows a more in depth breakdown so Ideally I need to not lose that functionality,
My only idea really is to create separate tables for each time range that only include data for the relevant dates however that seems like a very long winded approach.
The images are compressed as much as possible they are something like 30 bytes
This is what it looks like however it will eventually contain years of data with around 70 computed columns per row collating all the data I collect to produce the R/G for 5 separate categories. The user will filter between time ranges to only show the last 1, 7, 28, or 90 days however all of the dates are computed despite the fact lots of them are never seen again
1 Like
I would stick it all in a Glide Big Table.
You could create a couple of math columns to create the dates for 28 days ago and 90 days ago, and use those as filters.
2 Likes
Sorry, its not the storage I’m struggling with as theoretically it should last up to 60+ years as its just a row per date. I am just trying to optimise the performance to reduce the loading times when opening this tab as it is already taking up to 30 secs with only 2 years worth of dates in and only a month or so worth of actually data to compute.
Both Darren and I have understood your issue. That’s why we are suggesting you store the data in one table and display it from another.
If a screen is sourced to a table with up to 90 rows instead of 10k, it should load more quickly. That is our assumption.
Oh sorry yes I get you now, Thank you
1 Like
Hello to community my name is Sanjeev Mansotra. Yes, adding more rows to your Glide app could further decrease performance, especially on data-heavy screens like your analysis screen. As the data volume grows, load times may increase since Glide pulls data from your source (like Google Sheets or Glide Tables) each time. To optimize, consider breaking up data into smaller sets, using filters, or loading data conditionally to improve speed and user experience.
Yes, adding more rows to your Glide app could further decrease performance, especially on data-heavy screens like your analysis screen. As the data volume grows, load times may increase since Glide pulls data from your source (like Google Sheets or Glide Tables) each time. To optimize, consider breaking up data into smaller sets, using filters, or loading data conditionally to improve speed and user experience.
This is why I suggested a Big Table. With Big Tables, most of the data is kept server side, and rows are only sent to the device as needed. So in theory, the effective loading time on the device should be the same, whether you have 100 rows, or 10 million rows.
3 Likes
Hi, Unfortunately this didn’t work as well in practice as it did in theory. First of all it completely went over my head that you cant use computed columns in big tables as data for line charts which is necessary for my trend analysis, secondly, It is considerably slower, roughly taking double the time compared to how it was as a regular table.
However, potentially this is more scalable as it may always take this longer time regardless of how many rows in the app whereas the original may end up taking much longer down the line when there is much more data in the app.
You should be able to. Have you enabled the extra support for computed columns in Big Tables via Previews?
I think it depends on the type of computed column, and what it is referencing.
A simple math column that is referencing non-computed columns, for example, should work.
But others may not. Difficult to say whether or not your specific use case could be catered for without understanding more about it.
What do you recommend I do from here as ideally I need to improve the speed this page takes to load but I’m not sure what else to do from here?
What type of column are you trying to use there in your chart?