I don’t know if I can offer up an opinion if Relations or Filters are faster than the other. Most of what I’ve learned has been a lot of trial and error to make my own app run faster. I don’t think I’ve run across a scenario where I could directly compare the use of relations to filters.
Many times when I use relations though, they have a deeper purpose, such as needing associated Lookup columns, or Rollup columns to create summary totals. I often do not have a relation that stands alone without other column types that use that relation. For that reason, I’m stuck with using a relation over a filter.
If I were to honestly make a guess though, it’s probably not that much different. Like you said, a relation is more of a pointer to related rows. It’s not really transferring or moving any data.
I think the biggest determining factor for speed is how or when a table is accessed for the first time by a user. I think what happens is that when a table is accessed or needed in any capacity for the first time, then that’s when all calculations and computations are initially perform within that table. That could mean that you are accessing the table directly, or the table is being used through a relation or some other means. Once a table has been accessed and processed the first time, any subsequent calculations only happen on rows that have had data changed, and of course, any related rows that may be referred from, or referred to, are affected as well. I’ll use my app as an example. I have a table with 8k to 9k rows. There are a fair amount of calculations, and relations that link to and from other tables. I have made several improvements over the years, but I still have speed issues. But primarily, the tab is only slow to load the first time after the app is opened. If I leave the tab for another tab and come back, things open much quicker. My theory is that the large initial spin through the calculations is now done, so things become quicker. For my case, it’s a horrid situation where I have relations linking one table to another, and that other table has relations that link back, and there are other relations to other tables involved. It’s borderline an iterative or circular loop situation, but not quite.
I will also mention that I still have some logic contained in the google sheet. I have a weird situation where I have a table of lessons taught to students, a table of billing cycles (billing start and end dates) for the coach, and a hybrid query sheet that summarizes lessons, per student, per billing cycle, per coach. Lessons can be recorded before or after a billing cycle has been entered for a coach (this coach does not bill students on a normal predictable schedule). So I have to magically connect existing lessons (child rows), to a new billing cycle (parent row). I can’t use a billing cycle Row ID and attach it a Lesson when it’s recorded. I have to do that behind the scenes in the sheet. I did come up with an elaborate way to accomplish it within glide, but the number of additional relations and computed columns made the app horribly slow. Keep in mind it had to calculate this stuff 8000 times. I found it much more effective to just do what I did in the google sheet instead. It allowed me to create more efficient relations in glide as the results didn’t need to be immediately shown in the app.
I still have other things I want to try to make my app better, but like I said, it’s just a lot of trial and error and I think it can be very specific to your individual use case. Glide is quite powerful and can do a lot, but it’s good to have an understanding of everything it has to do behind the scenes…and especially at the mercy of the processing power of an end users device.
Glide is working to migrate apps to the same computation model that was developed for pages, so I do forsee performance improvements in the future. I don’t really know anything about the old or new computation model or how they work, but I do believe they are working to make things run faster in the future and more efficiently in the future.
