Do rows in other apps make apps slower?

[MattGlides]

The 13000 row app is obsolete and is currently just being used by one customer. Would exporting the data out to excel and deleting it help speed up other apps, or does it really not matter?

Also, does anyone have any clarity about what actually makes apps slower/quicker?

[MaximeBaker]

Can you give more context please?

[ThinhDinh]

@MattGlides

The 13000 row app is obsolete and is currently just being used by one customer. Would exporting the data out to excel and deleting it help speed up other apps, or does it really not matter?

When a user enters your app, they should only interact with the rows tied to that app.

@MattGlides

Also, does anyone have any clarity about what actually makes apps slower/quicker?

There’s a bunch of things that contributes to this, some of them being:

• Try to use relations instead of queries where you can. Queries on large datasets can significantly slow down performance.
• Compress images: Large images take longer to load, especially when you have them on the first tab the user’s going to load when they enter the app.
• Use row owners: This limits the amount of rows the user needs to “download” when they use the app. Less rows = less calculations needed, so it also helps.

A good write up from Jeff here.

App Performance Tips & Tricks: SPEED!

Tabs can have a benefit in some cases because some tables may not run computed columns until necessary. Less content on a page can have a benefit as there is less to render. I really don’t think this has an effect. I think the largest speed issues will depend on how your data is structured. Any computed columns that rely on the values of computed columns in multiple other rows will have a large impact. Ask yourself this question…will displaying something on a screen require multiple rel…

[Darren_Murphy]

@ThinhDinh

Try to use relations instead of queries where you can. Queries on large datasets can significantly slow down performance.

I’ve always been a little skeptical about this. Yes, I know Glide advises this, but I think there is a tendency to over estimate the impact. I use Queries quite liberally (I have a table in one App that has close to 100 query columns) and I’ve never noticed any performance issues.

[Jeff_Hager]

I’ve noticed quite difference between queries and relations in the past. In my case, running a query with a date range filter on each row in a 10k row table took considerably longer than doing a relation that simply finds a matching value on each row. The difference was my app completely crashing with the query setup, whereas the relation only caused a 5 to 10 second lag before rendering the tab screen. I think it depends on the situation, but in my case, all 10k rows need to process all computed columns in one shot instead of on demand. Three or four tables all linking up using computed columns before one of my tabs can display data. Once everything is loaded and processed initially, then the app works fine.