I think technically yes, but as I suggested it’s probably negligible in terms of impact on performance. I guess a much bigger factor would be what you subsequently do with those relations. For example, let’s say you create a relation to a table with 5k rows. And then you add a series of Lookup columns to fetch values via that relation. Then you might use the values from those lookups in a template, and then use that template to create another relation, and so on… All of this is going to create a much bigger computational load, because every calculation has to be done 5000 times.
But honestly, I think we might be making too much of this. The app I referred to earlier in this thread (the one with 30k+ rows) also has roughly 2000 computed columns, and at least 100-200 relations, with many of them being quite complex - lookups and math columns and if-then-else columns and templates - all feeding dynamic relations and constantly changing based on user interaction. And… the app works fine. So, at least in my experience, I think you need to do some pretty crazy stuff before you create any significant negative impact on app performance with computed columns.
Also, we know that in the not too distant future apps will be migrating to the NCM (New Computational Model), which can be expected to provide a bit of a performance boost.
Yeah, but as you noted earlier - relations only provide a pointer and don’t contain any actual data. So there is nothing to copy
If you had a lookup based on that relation, you could probably make a static copy of that. But all that would give you is exactly that - a static copy of the data, which would be redundant and no longer in sync with the data in the source table.
I hope i have summed up everything above and waiting for any new advice.
Glide Performance
This discusses the best practices to improve the performance of large Glide Apps with over 10k rows.
The biggest determining factor for speed and performance is when the a table is accessed for the first time. That is when all the computations are initially performed for all downloaded rows. After that, any new calculations or delays are caused only by the rows changed.
Row Owners
Using row owners appears to be the best step to improve app performance & speed.
Dont assign too many columns as row owners as Glide requires time to compute what to send to a users device.
Row owners allow less rows and hence less data downloaded to a users device.
Less rows downloaded means less computed column computations done on the end users device.
Glide Tables
Switch big tables into Glide Tables.
Synching with Google Sheets is limited in accordance with Glide plans. Seems like Glide Tables is the future for using Glide especially if you have big tables and require a lot of edits on your data.
Use Glide Tables & Glide will you. Google Sheet costs Glide a lot of .
In general the use of Glide tables does not speed things compared to the normal use of Google Sheet. Glide is storing a duplicate of all basic column data in Glide Tables. Computed columns are computed on the users device.
If you have a lot of data, working on Glide tables is more organized and faster than working with Google Sheets.
Computed Columns
Reduce computed columns.
Apps with a lot of computed columns appear to suffer in performance.
Reducing computed columns must improve performance. These computations are done on users device.
Computed columns should be fast.
You start to see issues if you have computed columns that rely on all relations to build first, and or relations that rely on all computed computed columns to run first. (examples …)
Don’t replace Glide Computed Columns for computations with Google Sheet Formulas. GS formulas create time delay and slow down the app performance more.
Glide is working to migrate apps to a new & better computation model developed for Glide Pages.
Relations
Reduce relations if possible ( Not very significant:thinking:)
A relation does not download all the data of related rows. It acts as a pointer to the related rows.
Relations to the same table are a bad practice.
Using Glide filtering capabilities is better than adding a relation column to filter rows.
Don’t use relations as sources of inline list. Use for deeper purposes such as needing a Lookup Column value.
Images
Dont worry too much about image columns.
Images are now downloaded the same way data is when loading the app. Only when an image appears on the screen is it downloaded.
Having multiple image columns or computed columns (which you don’t all use) isn’t an impact on app performance.
don’t take it too personal there was supposed to be a emoji after that
not really sure why you need lookup columns to use in the inline list?
i’m just summing up the opinions above… personally i think its very similar in performance and very organized with relations. i do use them a lot even when I don’t need them for display.
saving app building time isn’t really the biggest concern in this thread. dealing with live apps over 10k rows, and live edits … just trying to build an understanding of whats best for app performance/speed for the users on it.
not really sure why you need lookup columns to use in the inline list?
Let us assume we are using the Details Layout (style) on a Tab called X (which points to table called X) to put an InLine List and read data belonging to another table (e.g. table Z). To do it without a relation you must create several lookup columns to retrieve values from table Z and fill Inline’s settings out and even, the Details screen associated to each item.
Too many steps, too much data to handle and too much wasted/invested time. To avoid all this, the smartest solution is create/use a relation if possible, you won’t have to create any new columns (lookup) for it.
I’m not sure but i am confused with what you said, please correct me where I am wrong. I have several examples where I don’t use a relation and lookup columns are not needed.
Tab/Table X = Admin Panel
Table Z = Orders (has an if/else column isProcessed = True/False
Tab X is just a detail screen 1 row table. Inside the tab i can have an inline list from Table Z and show any value necessary without any lookup columns. I can filter it by isProcessed = True and I get all processed orders.
i could also however from the data editor in table X have a relation column to table Z that returns all isProcessed orders. and then display that in the layout.
personally i feel both are very close in performance …?
I was talking (or writing) about my case when I used to do this kind of things in my first months using Glide.
I don’t remember well if the Inline List always was able to work with a relation but in 2019-2020 I didn’t know it and used to create many lookup columns in order to work with an Inline list which pointed to another table. Suddenly, I noticed that I could work with a relation directly with an Inline list and everything improved and my life was happier. Since then I use relations with no problems and with no mercy!
Which is better in performance for working with an Inline list: a filter or a relation? I still don’t know but depending on case and complexity (I always try to avoid creating unnecessary computed columns) I can use any of them.
@gvalero No worries. A lot has changed since the old days Glide! I have removed the point as well its not clear and the one above it is very similar
here is the summary again. for anyone who needs it or wants to contribute to it
Glide Performance
This discusses the best practices to improve the performance of large Glide Apps with over 10k rows.
The biggest determining factor for speed and performance is when the a table is accessed for the first time. That is when all the computations are initially performed for all downloaded rows. After that, any new calculations or delays are caused only by the rows changed.
Row Owners
Using row owners appears to be the best step to improve app performance & speed.
Dont assign too many columns as row owners as Glide requires time to compute what to send to a users device.
Row owners allow less rows and hence less data downloaded to a users device.
Less rows downloaded means less computed column computations done on the end users device.
Glide Tables
Switch big tables into Glide Tables.
Synching with Google Sheets is limited in accordance with Glide plans. Seems like Glide Tables is the future for using Glide especially if you have big tables and require a lot of edits on your data.
Use Glide Tables & Glide will you. Google Sheet costs Glide a lot of .
In general the use of Glide tables does not speed things compared to the normal use of Google Sheet. Glide is storing a duplicate of all basic column data in Glide Tables. Computed columns are computed on the users device.
If you have a lot of data, working on Glide tables is more organized and faster than working with Google Sheets.
Computed Columns
Reduce computed columns.
Apps with a lot of computed columns appear to suffer in performance.
Reducing computed columns must improve performance. These computations are done on users device.
Computed columns should be fast.
You start to see issues if you have computed columns that rely on all relations to build first, and or relations that rely on all computed computed columns to run first. (examples …)
Don’t replace Glide Computed Columns for computations with Google Sheet Formulas. GS formulas create time delay and slow down the app performance more.
Glide is working to migrate apps to a new & better computation model developed for Glide Pages.
Relations
Reduce relations if possible ( Not very significant )
A relation does not download all the data of related rows. It acts as a pointer to the related rows.
Relations to the same table are a bad practice.
Using Glide filtering capabilities is better for performance than adding a relation column to filter rows. (I feel exactly same performance )
Images
Dont worry too much about image columns.
Images are now downloaded the same way data is when loading the app. Only when an image appears on the screen is it downloaded.
Having multiple image columns or computed columns (which you don’t all use) isn’t an impact on app performance.
[/quote]
I think you’re making way too much out of this. If I was completely new to Glide and read this, I’d be terrified of using computed columns for fear that my app would grind to a halt. And you definitely don’t want to be steering people away from computed columns, because this is where all the Glide magic happens. As I noted earlier in the thread…
…and it’s not something that your average user even needs to bother themselves with (even with >10k rows).
Yes you could be right. I’m sure computed columns are great. They do create a lot of magic. It is impossible to avoid them and a great bonus to use them.
I can tell you though, I am using Glide on a live app that manages orders received. There are 2 big tables Orders & Items and performance wise the app suffered with as low as 5k rows if not lower. The delay in loading the app the first time is big that even with 5g internet you might need to try to open a few times for the data to download.
and although we don’t have a scary amount of columns, but its maybe in the hundreds. its very likely unused or not very necessary computed columns is a major reason in that in addition to some other reasons …
I think I agree with what @Darren_Murphy is saying. It’s nice to have some general guidelines, but it’s really dependent on the situation. Most issues that I’ve ran into are because I’m doing some really crazy stuff. Crazy enough that I know how it works, but don’t think I could ever explain to someone else how it works. I wouldn’t say that I have an unusually large amount of rows or columns, but it’s the way that I have everything so deeply interconnected, that a lot of calculations have to occur in multiple tables before the results can be displayed.
A lot of people ask how to make their app faster, but I think there are so many variables to consider, so it’s hard to give a definitive answer or reliable advice. I tend to learn what works and what doesn’t work by always trying different things to improve my app. Sometimes I find a winning solution, and sometimes it makes things worse. It’s just a lot of trial and error and techniques that can only be learned through experience. Some things are obvious, like not trying to show 10k rows of data, loaded with tons of images, on a single screen. On the other hand, other things are less obvious, such as how glide processes through the data and what’s actually happening when you open an app and navigate around. Most of my assumptions are simply through experience with working with the platform.
I think these guidelines are helpful for getting a general idea of how glide works, and I think that’s the important thing…learning and experiencing how glide works and functions. Once you grasp that, then everything else becomes much easier and you can start to come up with crazy solutions to complicated problems. Once you start to understand what’s happening behind the scenes, then you can start to understand what may or may not be the best practice to get something done.
In general, glide is trying to make it easy on us so we don’t have to think about these things. They may not be 100% there yet, but I can tell you that things are light years ahead of where there were when I started using glide three years ago. New features over the years have allowed me to restructure and simplify things in my app to make it better and faster. A lot of logic that could only be accomplished in a google sheet in the beginning (before we had a data editor or computed columns) has now been switched to use glide computed columns. Some logic still remains in my google sheet, simply because I haven’t been able to duplicate it in glide, or for my particular use case, it just helped things run faster by lessening the load on glide. I still have a ways to go, and as my dataset grows, it becomes more imperative to find solutions. I’m sure at some point I’ll just have to completely rethink how parts of my app work, and honestly, I may have to resort to some javascript to make that happen. Or maybe glide will come out with new functionality or features that will make some of these things work much better.
The biggest determining factor for speed and performance is when the a table is accessed for the first time. That is when all the computations are initially performed for all downloaded rows. After that, any new calculations or delays are caused only by the rows changed.
Using row owners appears to be the best step to improve app performance & speed.
Dont assign too many columns as row owners as Glide requires time to compute what to send to a users device.
Synching with Google Sheets is limited in accordance with Glide plans. Seems like Glide Tables is the future for using Glide especially if you have big tables and require a lot of edits on your data.
you. Google Sheet costs Glide a lot of 
.
Glide is working to migrate apps to a new & better computation model developed for Glide Pages.
, it’s just a joke
(I feel exactly same performance 
)