Hi guys
What is the main reason for poor performance? rows or layout?
some tips please
Hmmm…can you be a little more speciic?
For example, I have a map feature that I wish would load more quickly. I think it is slow due to the large number of map pins I have on the app.
1 Like
Exactly, that’s what I mean. that affects the performance of the app more if the design (as is your case) or a large number of rows.
does it improve performance by making row owners?
example
I am working on an app where there are around 5000 public rows and in theory another thousand with row owners
I’m not sure how well it would work.
There really isn’t an easy answer unless you just try it. There’s a lot of things to consider.
-
How much data is being downloaded? Row Owners can make a difference because that will mean there is less data downloaded instead of the entire database.
-
How many computed columns do you have? Computations will need to happen on the end user’s device and if there is a lot of them on a lot of rows, that can take some time.
-
Do you use computed columns to build relations? I’ve had lag in my app because I have some relations that depend on computed columns. So all of those computations need to happen before the relations can build.
-
How much data are you showing on the screen? Large inline lists have to build the associated html and render it on the screen.
-
How many images are you loading? Whenever you load a screen that has images, those images need to be downloaded, cached, and rendered on the screen.
-
Are you using any distance columns or map pins? Addresses and coordinates need to be geocoded to mathematically calculate distances. They also need to mathematically calculate where to place the pin on map, which also needs to download and render any background imagery.
Like I said, there isn’t a straight forward answer to this. There’s a lot that happens behind the scenes as far as downloading data, process it through code, and displaying it in the app. My primary app is between 8500 and 9000 rows. Most of it works very well, but one part of it is slow because it has to do a lot of background processing to do any calculations and build relations between multiple tables before it can display anything. Once it does those calculations initially, after the app is opened, then it works just fine until the app is closed.
The best thing is to plug in a bunch of test data and just see how the app responds. This should be really easy to do if you are using google sheets. If you are using glide tables, then it’s a little more work to generate a bunch of rows of test data, but you can always create some temporary actions that will add rows, and then later delete them.
A lot of things can contribute to performance issues, but it all depends on your particular app, how the database is designed, and how the interface is designed. You can have 100,000 rows with only a few basic columns and do nothing but display 5 of those rows. Glide might be able to handle it without any issues, but adding just one computed column means that the user’s device has to do 100,000 calculations on that one column. Adding more computed columns means more calculations need to occur on all of those rows. Adding images means all of those images need to be downloaded and cached for all rows. Adding distance columns or a map means geocoding and distance calculations need to occur on all rows. How many computed columns depend on other computed columns? It all can add up to be a lot of background processing. It’s just trial and error to find the most efficient way to set things up so the app has to do the least amount of work as efficiently as possible. Once you start to think about how much is happening behind the scenes, then it starts to make sense what you may or need to change to make the app more efficient. Sometimes you just need to rethink how screens are designed and the data is set up to find the right balance of speed, efficiency, and user experience.
9 Likes
excellent answer, gave me some ideas of what to do
Thanks. regards!
1 Like
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.