Speed up load time for a App

[Gustavo_Eduardo]

Good morning everyone. I leave you a query. Maybe it will help people a lot. How to clean up the “schedule” of an Appsheet app (so to speak) so that it loads faster? Did you notice that as the app gets bigger, every time we hit “save” it takes longer to load? Well they could be "tips" to speed up the loading of apps. have a nice day

[WillowMobileSys · Accepted solution]

Your are correct.  There have been many Tip posts over the years but like all posts they eventually fade out.  It might be best if there was an article written, @Steve , something more static that stays around, to provide a list of steps an App Creator could go through.  I'll start one here.

First, if you are not aware, there is a Performance Analyzer in the Manage section.  You can drill into each logged App Sync and see where the Sync time is being impacted.  99 times out of 100 it will be Virtual Column re-calculations that take up the most time.  BUT that doesn't mean you need to get rid of Virtual Columns.  They are a vital part of an app.  The trick is to get that re-calculation time reduced to a minimum.

Things to try reducing Sync times from easiest to hardest

• Crop the sheets to just the data.  Having blank columns and rows are empty space that has to be checked if data is there or not.  By removing them, those empty spaces are eliminated from the loading process.
• Delete old/test data rows no longer needed. 
• Apply Security Filters.  
• Eliminate unnecessary Virtual Columns.  Some virtual columns are better as normal columns - e.g. a Column which concatenates several columns from the same row does not need to be a Virtual Column. A normal column with the App Formula set will serve just as well and will only re-calculate when the row changes.
• Reduce complexity of expressions in Virtual Columns - Some Virtual Columns columns I have seen are extremely complex which adds to computation time.  However, there might be portions of that expression that only change when the row changes.  By moving those parts to normal columns, that portion of the re-calculation is removed from the Sync time.
• Improve implementations to increase efficiency - We build an app based on what we know but later realize there is a better way.  Many times that "better way" will reduce complexity and increase efficiency which will translate into improved Sync times.
• Consider app usage and app restructuring - Maybe a single large app is no longer viable.  Breaking it up into smaller apps will usually result in each app needing a smaller footprint requiring less Sync time to load.

I'm sure there are other considerations that others can chime in with to help put. 

[Gustavo_Eduardo]

Agradezco todos estos datos y apoyo la moción de que se cree un artículo con todos estos tips

[SkrOYC]

---

@Gustavo_Eduardo wrote:

every time we hit “save” it takes longer to load?

---

Yes and eventhough @WillowMobileSys's suggestions are exactly what we need to consider when app-performance is a problem, this will translate to the developing process because everytime we "save" changes the backend makes some changes in the background and the emulator gets relaunched. That's part of the reason I don't use it. The bigger the app, the more changes need to be made everytime you update something and hit "save". Also, try simpler changes and see if those take less time to save.

In general, if you make more efficient apps the editor will also perform more efficiently by nature

[WillowMobileSys]

@Gustavo_Eduardo 

Oh wait,  this post was about loading of the app definition, not about Sync time?  Sorry if I caused confusion.  

[jyothis_m]

---

@WillowMobileSys wrote:

99 times out of 100 it will be Virtual Column re-calculations that take up the most time. 

---

Exactly @WillowMobileSys . But i see lot of reverse reference virtual columns which is the main culprit. Any other option possible. I need ref but reverse reference not needed in most of cases. Is there anyway i can get rid of these virtual column calculation time that occupies major part of the sync time.

[SkrOYC]

---

@jyothis_m wrote:

I need ref but reverse reference not needed in most of cases. Is there anyway i can get rid of these virtual column calculation time that occupies major part of the sync time

---

Enum basetype Ref. Don't forget the Valid_If list of options

[jyothis_m]

Thank you 😊 Will the dereference expressions work in that case. 

[SkrOYC]

Absolutely.

Check this post by @MultiTech 

Use Enum/EnumList (Base Type: REF) to De-Reference... - Google Cloud Community

[jyothis_m]

Thank you ☺️ @SkrOYC for this. Should have really read this long before.

[Suvrutt_Gurjar]

Hi @jyothis_m 

---

@jyothis_m wrote:

But i see lot of reverse reference virtual columns which is the main culprit.

---

The reverse reference VCs typically do not take up large sync time. Manually created VCs such as with multirow SELECT(), FILTERS() could take up large sync time. Please go through a very informative post wherein @pravse and other community colleagues have discussed valuable insights on performance issues.

Solved: Improving performance by getting rid of unnecessar... - Google Cloud Community

[jyothis_m]

Thank you 😊 @Suvrutt_Gurjar 

[Suvrutt_Gurjar]

@jyothis_m 

As an example in one of the test apps, the below reverse reference column has taken just 0.03 seconds to compute.

Each of the related records list  in that column has anywhere between 100-1000 related records from the child table as the following figure shows related values returned for just one parent ID. And the parent table has 5000 records.

On the other hand below are some VCs in the same app that have heavy SELECT() formulas and they start taking time.

Of course , there are exceptions in some cases. Please do share your observations if you can. Recently we responded to a post on reverse VCs taking time. I will share that post when I locate it.

[SkrOYC]

I have a guess that if a certain dataset is child of another one and the child has unefficient expressions, the parent's [Related] VC will take time to load as well

[Suvrutt_Gurjar]

Yes, your observation is right. It is possible for some reverse reference Vcs to be inefficient. There will always be outliers cases. By rule of thumb, I believe heavy multirow SELECT(), FILTER(), MAXROW(), MINROW() functions based manually created VCs eat up more time than system generated reverse reference columns.

[jyothis_m]

Though i do not have any VC with any of these expressions, but most of my Tables in the app has Ref to one single Table. This single Table therefore contains more than 10 VC with Reverse Ref which is showing as taking max percentage of VC Calculation Time in the Performance Analyser page.

[WillowMobileSys]

It really depends on what your overall Sync time is? 

VC's will take up most of the Sync time regardless.  The question is if the overall Sync time is good or not to begin with.  App size needs to be considered in that analysis.

[Suvrutt_Gurjar]

I totally concur with @WillowMobileSys 

[SkrOYC]

---

@Suvrutt_Gurjar wrote:

The reverse reference VCs typically do not take up large sync time

---

Re: Introducing Virtual Column calculation time in... - Google Cloud Community

[Suvrutt_Gurjar]

Thank you @SkrOYC 

I am sure others will share their thoughts. I respect your opinion. 

[jyothis_m]

---

@Suvrutt_Gurjar wrote:

Please do share your observations if you can.

---

Ofcourse @Suvrutt_Gurjar I shall check my apps once again and post it here. Thank you once again. 

[Steve]

Virtual columns with queries (FILTER(), LOOKUP(), MAXROW(), MINROW(), and SELECT()) are the most common causes of poor sync performance and are where you should focus your analysis when addressing slow sync.

REF_ROWS() is technically a query, but is much more efficient than the others and much less likely to adversely affect sync time.

The app editor load time is definitely affected by the complexity of your app configuration: the larger and/or more feature-filled your app, the longer it will take to reload the app editor.

An easy win to speed the app editor load is to close the app emulator drawer when saving. When the app emulator drawer is closed during a save, the app will not be loaded when the app editor reloads. If you're making and saving several changes you don't need to test in the app emulator (e.g., adding or removing multiple tables, regenerating columns of multiple tables), close the emulator drawer.

When the app editor (re)loads, it re-validates nearly everything in your app: every setting, every expression, every association (views to tables, actions to tables, slices to tables, columns in slices, columns in views, etc., etc., etc.), and so on. When you use Save and Verify Data, it verifies even more (presence of associated files, template validity, structure and some content of data sources, etc.). The more configuration your app has, the longer this process takes.

[Suvrutt_Gurjar]

Thank you very much @Steve for a succinct write up on virtual columns and emulator behavior. I have bookmarked this post for my own reference.

[jyothis_m]

Thank you @Steve . May i ask one more thing @Suvrutt_Gurjar @Steve @WillowMobileSys @SkrOYC @Gustavo_Eduardo 

What is the max sync time that your bigger apps are taking. According to your opinion how much max sync time can be allowed before going for splitting the app into smaller ones. 

[Steve]

I'm afraid I have no specific guidance to share here.

[jyothis_m]

No issues at all. Thanks for the reply 😊

[WillowMobileSys]

This is a tough one to answer.  There are no real metrics to help gauge this.  I will say that the ultimate litmus test that your app may be slow will be from the users themselves. 

If you get several complaints then it's definitely time to dig in and try to speed things up.  In the meantime, you can only do what you can to keep the Sync time as low as possible.  And don't let the concern of potential impact to Sync time prevent you from implementing what you need to!

[SkrOYC]

---

@jyothis_m wrote:

What is the max sync time that your bigger apps are taking

---

I'm completely remaking my first app that was between 90-120 seconds per sync.
Now it's a little bit under but I'm remaking it anyway, doing a V3 from the ground up

[jyothis_m]

Thank you 😊 @Steve @SkrOYC @WillowMobileSys 

[Suvrutt_Gurjar]

Hi @

@pravse wrote:

So that’s a good rule of thumb. Syncs should be under 10 seconds. Maybe 15 max. Otherwise, you most likely have (a) too many tables — break up your app into sub apps with a launcher, (b) too much data — use security filters, © inefficient SELECTS in the security filters, or (d) inefficient SELECTS in the virtual columns

---

Did you get a chance to go through the post on performance I had shared? The above quote is from that post. Please take time to go through that post because it has very valuable insights from @pravse who headed AppSheet and he is and the main architects of AppSheet. The post has also insights from our senior community colleague @Steve 

I think your question is somewhat like "what shirt size one should buy?" 🙂  I think there is no "one (app sync) size that fits all"🙂

@WillowMobileSys 's guidance is also good. If many users are complaining it being slow, then you may need to act.  There are some inherent factors such as subscription plan used. This translates to  you get what you pay for. 

Then as all have guided, with your app design that you can control to large extent ( number of tables and VCs) . 

[jyothis_m]

Thanks a lot 😊 @Suvrutt_Gurjar 

---

@Suvrutt_Gurjar wrote:

Did you get a chance to go through the post on performance I had shared?

---

Yes I have gone through the post and you are correct. I contains really valuable insights. 

---

@Suvrutt_Gurjar wrote:

I think your question is somewhat like "what shirt size one should buy?"   I think there is no "one (app sync) size that fits all"

---

Sorry for that 😀

[jyothis_m]

I removed all reverse reference VCs from my app by using Enum with REF instead of direct REF. Around 20+ VCs removed and I confirm that you were correct when you told that REF_ROWS() won't affect that much. I only had a slight reduction in sync time not noticeable at all sometimes. 

And i want to add that my app with around 60 tables takes about 20 secs during initial startup, thereafter sync takes <5 sec. I know 60 tables might be too much, but here i have no other option but a single app. I will try further to improve the sync time. The chart showing VC calculation time is having some issues i think. Its not showing up sometimes. As told by @SkrOYC I think the appsheet team has to look into that part. 

Thanks to all of you for all the valuable insights. @Suvrutt_Gurjar @Gustavo_Eduardo @WillowMobileSys @SkrOYC @Steve 

[Suvrutt_Gurjar]

Thank you for your updates @jyothis_m . 60 tables is definitely a large number of tables. If you take a look at the thumb rule shared by @pravse , your 20 second sync time exactly matches with what he has mentioned.  He has mentioned N/3 as latency which is 60/3 =20 seconds. 

[jyothis_m]

That was a good finding that i missed. Thank you once again 😊 @Suvrutt_Gurjar 

---

@Suvrutt_Gurjar wrote:

60 tables is definitely a large number of tables

---

But i have no other option here. Need a single app for all those data. Its working fine otherwise. Only initial startup taking about 20 sec

[Suvrutt_Gurjar]

Oh okay. If 60 tables are necessary, then I think your users will need to live with increased sync time of 20 seconds which is not bad if you are having 60 tables and also non enterprise subscription plan. Of course you have not mentioned your subscription plan but even with enterprise subscription plan, I believe sync time may not drastically reduce.

I think, AppSheet typically recommends 10-20  tables per app. Of course many apps may exceed this number but I  believe 60 is still on a much higher side.

[jyothis_m]

i totally agree with you @Suvrutt_Gurjar  May be i will have to find some other option soon with this much of tables and data before the sync times crosses tolerable limits. 

[SkrOYC]

---

@Suvrutt_Gurjar wrote:

There are some inherent factors such as subscription plan used. This translates to  you get what you pay for. 

---

💯