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
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.
7 Likes
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
Oh wait, this post was about loading of the app definition, not about Sync time? Sorry if I caused confusion.
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.
Enum basetype Ref. Don’t forget the Valid_If list of options
3 Likes
Agradezco todos estos datos y apoyo la moción de que se cree un artículo con todos estos tips
1 Like
Thank you 
Will the dereference expressions work in that case.
Absolutely.
Check this post by @MultiTech
Use Enum/EnumList (Base Type: REF) to De-Reference… - Google Cloud Community
2 Likes
Thank you 
@SkrOYC for this. Should have really read this long before.
1 Like
Hi @jyothis_m
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
1 Like
Thank you @Suvrutt_Gurjar
[quote=“Suvrutt_Gurjar”]
The reverse reference VCs typically do not take up large sync time
[/quote]##### Re: Introducing Virtual Column calculation time in… - Google Cloud Community
2 Likes
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.
2 Likes
Thank you @SkrOYC
I am sure others will share their thoughts. I respect your opinion.
2 Likes
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
2 Likes
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.
3 Likes
Ofcourse @Suvrutt_Gurjar I shall check my apps once again and post it here. Thank you once again.
1 Like
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.
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.
3 Likes