I’ve been restructuring my app for two reasons - make it easier to manage, and hopefully make it faster.
By using helper tables I was able to reduce the total number of columns in one large table from 205 to 120. (All the columns that were shifted to a helper table are computed columns). Since the table currently has over 4K rows, my conclusion is that’s 340,000 fewer cells for Glide to compute in the table in question.
Yet Performance mode says the maximum column for that table in the old version took 48.8999 ms to compute and the new version took 48.1999. (The times fluctuate, but these are typical).
Did moving all those computations to a different table save a whole 0.7 milliseconds? I know Performance mode isn’t really the final word on performance, but I would have thought ditching 80 columns would have made a difference. Is there some structural reason that rows matter but columns don’t?
First up, I think Performance Mode is reporting the max compute time of a single computed column in that table, not the aggregate time across all columns.
If your slowest column depends on other computed columns (or queries), the chain’s bottleneck remains. Moving columns to a helper table doesn’t help if the relation/query/lookup patterns still force the same work.
What I think you should do is open the analyzer and hover per computed column - sort out which exact column hits 48 ms. Optimize that one. Then check the front-end to see if loading time has been improved.
Of course, that makes sense. It does say “maximum” after all. Thanks for the strategy tip.
1 Like
My rule is not using query too much unless it’s absolutely necessary, and don’t try to do relations/queries to the same table.
Interesting - do you have any rules of thumb about the times you strive for using performance mode?
When you say don’t do relations/queries to the same table, could you say exactly what you mean? Because I think I do that a lot. Example, Jobs > Items is a one-to-many relation. Then I have queries in the Jobs table based on that one-to-many relation. Is that what you’re talking about? It just seems easier to query than using a lot of if-then statements and making different relations on those. Or do you mean something else?
From the look of it, I shouldn’t work with dates unless absolutely necessary. Sometimes even a basic date column is the slowest! 
I don’t build apps for myself, so my rule of thumb is checking after the first build and every once in a while.
I mean targetting the same table you’re creating the query/relation from. Jobs > Items are different tables.
Yeah, for some reason they always take a lot of time to calculate basic columns, I assume due to formatting and timezones.