I have a number of creates (RowAdds) using custom forms that - on first use - are wicked slow. Like 30 seconds before the screen becomes responsive. The screen appears but none of the components are ‘active’.
Below is the ‘standard’ logic I use for all these custom forms. For example, (rel->WPost) is a column in the User Profile table in a Sheets. W CRUD Post is a SHEET tab containing the ‘custom form’ data including the ‘creator’ which links back to the USER table (rel->WPost where User.email == Creator).
On first use this process can take 30 seconds before the table becomes “active” and I am guessing that is because of the back and forth between Glide and the SHEET. It is a poor user experience (from their perspective it becomes slow ‘randomly’)
I need to fix this but not sure what the best next step is (I was going to move all the ‘working’ tables from SHEETs to Glide Tables and adjust ALL the actions in “the hope” it would fix it). This is at least a day of work, maybe two with testing.
Any thoughts on why a Screen ‘loads’ slow or thoughts on why the first use a Screen is very slow to ‘activate’ (but again, the screen pops up quickly, the user just can’t do/edit anything).
If you’ve got stuff that’s waiting for data to sync between Glide and a Google Sheet, that will definitely slow things down.
I can’t say for sure if that’s your problem here, but I use a lot of Helper/Work tables, and I would never ever use a Google Sheet for this purpose. Always a Glide Table.
Is your understanding that the fact that I am creating relations between two SHEETs tabs (AddRow within a SHEETS tab, creating a Relation between the User and Working table and then using that ROW in the edit) rather than using Glide Table for the working table be a source of slowness issue?
If so I will try it migrating one SHEET to a Glide table and measure the results.
Results of first test (times estimated) verifying that First Access is much slower than Second Access.
Working Tables
First Access Time
Second Access Time
O1
30 secs
0 sec
O2
31 secs
0 sec
O3
0 sec
0 sec
O4
47 secs
0 sec
O5
60 secs
0 sec
I tested O3 twice and both times it was editable immediately. Not sure why - more to discover but I will update this table with new ‘first access time’ once I move Working Table over to Glide from Sheets. Will take a while.
Quick Update - I thought Row Owners might have slowed things down so I checked and I have Row Owners only set in O3 (which responded immediately) but NOT in any of the other working table. Hmmm…
I don’t think google sheets vs glide tables is going to make that big of a difference. Glide is already storing a copy of your sheet data and the app is only syncing with glide’s copy. The biggest issue with google sheets is if you have calculations that are happening in the sheet instead of happening in glide. It takes time for those sheet calculations to sync back to glide. I think the real issue is that all of your data needs to first sync to the end user’s device, then all of those computed columns need to run initially on the user device once that table is accessed for the first time. Having multiple tables all interlinked means all data in all of those tables needs to compute, and all of those relations need to build when any one of those tables is accessed the first time. This is especially true if columns used for relations are computed columns themselves, such as a template.
Row Owners won’t slow things down. In fact it will speed things up because there is less data sent to the user’s device, and thus less computations that need to run.
I have similar issues with initial load slowness when I access a certain tab in my app. I also know that I have 10k rows all interconnected across a few tables. I’ve done several things to trim it down and make it more efficient, but I’m not completely there yet. It just becomes a massive computation load when tables are loaded and accessed initially on the user’s device. I am really curious how my app will react once the new computation model is released. Otherwise I might resort to a script that will periodically archive old data into a separate unused sheet tab. 99% of my data is derived from input from one user over the course of 3 years, so row owners is kind of out of the question…(unless I do apply row owners, and then slowly alter the email in the oldest rows so they essentially become unowned, but still in the table, and no longer downloaded to the device. )
BTW - I looked at the complexity of my working tables which range from 6 relations, 9 templates and 5 lookups to one relation (8 items in sheet) and one lookup. They all seem to take 30-60 seconds to ‘activate’ except from the one, odd duck which activates immediately (3 relations, 3 lookups, 3 templates).
I will wait until the NCM comes out before spending time changing things and just explain it will be slow the first time something is used but fast after that and that it is not ‘random’.
Yeah, it’s kind of frustrating. On one hand I’m not sure what I need to do at this point to make my app faster, short of trimming out unused data, or attempting to reduce the number of computed columns. On the other hand I have a reasonable understanding of how glide is designed to work in it’s current iteration, so I can fully understand why it’s slow, which is mainly because the end user’s device is doing all the computation processing rather than the server.
The capability of the device will make a difference too. I have a tab in my app that takes 12 seconds to initially open for me. My GF’s phone will open it in about half that time. My phone is cheap and old. Her phone is expensive and old. A brand new high end phone will probably process all of that data in a fraction of the time and probably open the same tab in a couple of seconds.
I’ll also give a piece of advice that I normally would never recommend to anyone. I have a series of VLOOKUP’s in my largest table (8k to 10k rows). This is so I can dynamically get a value that I can use later to build a relation within glide to and from another table. I am able to successfully replicate this process in glide with a series of computed columns, but the exponential number of computations caused the tab to take anywhere from 30 to 60 seconds to open. It was just too much computation to push off onto the user, and especially a computation that should happen only once instead of every time the app is opened. Instead I reverted from using glide computed columns, back to the vlookup in the google sheet. This offloads the computations, that determine that value, to the google sheet, and Glide will only see it as a basic column value.
So in some respects, if timeliness is not crucial, and you can reasonably get away with waiting a few seconds to a few minutes for sheet values to calculate and sync back to glide, then it may actually improve app performance to some degree if you offload some processing to the google sheet. I think that’s Glide’s ultimate end goal too. I think they are working to improve performance by moving some processing from the user device to the server. Then it may be possible that computations will only need to happen on the rows that are affected by data changes, much like how google sheets work today. I think we’ll get there eventually. Until then, it’s just a matter of trying to make tables as efficient as possible.
)