Table Performance Issues When Displaying 70,000 Records

[11198]

I am building an app with 70,000 records. The structure is very simple, and I am using almost no virtual columns.

With Server Caching turned ON, the sync process completes quickly, so the data loading performance is good.

The issue arises during app operations. I am displaying all 70,000 records in a single Table View, but interactions within the Table View feel very slow.

Is it possible that AppSheet's structural limitations cause performance issues when displaying such a large number of records in a single view?

I would like to understand the root cause of this issue and learn about potential solutions.

Thank you in advance for your help.

[Steve]

---

@11198 wrote:

Is it possible that AppSheet's structural limitations cause performance issues when displaying such a large number of records in a single view?

---

That would be true of any app, would it not?

Are images involved? Are you using Show? expressions?

"Almost no virtual columns" isn't "no virtual columns", so what are those virtual columns doing?

[11198]

Thank you for your response.

In my app, there are only four virtual columns used to concatenate text values within the same record. I believe these should not have a significant impact on performance. Additionally, there are no Image or Show-type columns in the table.

What I wanted to understand is how performance behaves with large datasets. I think app performance can be classified into two types:

• Backend performance, such as sync speed or data loading, which can be observed in the performance profile.
• Frontend performance, where displaying a large number of records in a single View causes slow interactions on the app screen.

In this case, the backend performance seems to be fine. However, the frontend performance is poor, as the app becomes slow when handling a large number of records in a single View.

I would like to know if there are any methods to improve this frontend performance issue.

Thank you.

[Steve · Accepted solution]

Your assessment is sound. It would appear AppSheet is limited by the size of your dataset. I'm afraid I have no guidance to offer here--I've never had to display that much data in a single view.

[11198]

Thank you for your response.

I agree that displaying such a large amount of data in a single View is not typical.

It has been very helpful to understand that there are no feasible solutions for this scenario. I will proceed by creating a mechanism to reduce the amount of data displayed.

I truly appreciate your assistance.

[Steve]

Attn @Suvrutt_Gurjar @MultiTech @AleksiAlkio 

[AleksiAlkio]

Do you have any format rules or actions with a condition?

[Suvrutt_Gurjar]

I think Steve has summed it up well. One more point that you may want to ascertain is if there are any expensive format rules for that view.

Format Rules: The Essentials - AppSheet Help

Just in case there are format rules with extensive computations, please also go through an informative post on that topic below where @pravse  the former CEO and architect of AppSheet as well as senior community colleague @Koichi_Tsuji  have some insightful comments on the topic.

Solved: Disabled (expensive) Format-rules vs performance - Google Cloud Community

In any case, yes, presenting 70 K records in a single view may be avoidable for the user experience as well.

[MultiTech]

---

@11198 wrote:

In my app, there are only four virtual columns used to concatenate text values within the same record. I believe these should not have a significant impact on performance.

---

It will still be impacting things, though not too heavily.

Whenever you get to tables over 50k records, there's a few rules I follow:

1. Minimal ref connections (like 1)
   • all others need to be soft references to avoid the reverse reference
2. No virtual columns if you can get away with it
   • This might mean you have to build actions/automations to update values that would otherwise be dynamic virtual columns.
3. Minimal formatting rules and slice criteria
   • They can't include dereferences or anything heavy.
4. Minimal use
   • Anything that uses this table needs to do so efficiently.  (You can't have a VC that pulls a list of something from this table; too heavy.)