reduce saving time in editor

[Gustavo_Eduardo]

Dear experts,

I imagine that as you develop, you may have noticed that the processing time for your data (when saving changes in the editor) increases as the size of your apps grows. I ask myself, “What is the cause of this?”

I’ve come up with some answers and have acted accordingly, as dealing with the bottleneck of waiting after each save becomes quite frustrating.

• First, I minimized the use of virtual columns (I hardly have any).

• I created a system that saves expressions in real columns, which are calculated once when the form is opened, and instead of writing them directly in the show ifs or valid ifs, I reuse them. In other words, instead of writing them 50 times, I write them once, and they are calculated once, avoiding unnecessary recalculations. I don’t know if it’s a coincidence or what, but I’ve managed (contrary to what my reason suggested) to achieve significant reductions in save times when making changes in the editor.

Do any of you have any ideas about the factors that influence data saving, and what can be done to make the process more manageable as apps grow?

[Aurelien]

Hi @Gustavo_Eduardo 

I agree with your suggestion, they are perfect in the process of optimizing final user experience. I do the same.

Hoewever, if you are only speaking of EDITOR use, you simply need to create two apps: 

- one for development

- one for production

The development one will use a different set of data, reduced at the minimum.

Eventually, you can use this step to push it in your production app:

Upgrade an app - AppSheet Help

[Gustavo_Eduardo]

Dear @Aurelien,

When you say:

@Aurelien wrote:
I agree with your suggestion, they are perfect in the process of optimizing final user experience. I do the same.

Are you referring to the idea of creating columns in the database to store temporary data (like show_if, valid_if, etc.)? Because if that’s the case, I once tried it and it worked for me, although I’m not sure why it works.

My doubt arises because I have frequently discussed this topic, and even Steve has responded. There’s a post dedicated to "performance" that I opened in the Tips & Tricks section. What I gathered from several discussions is that, apparently:

"The practice of creating new fields in the database to store expressions just once—so that they can be reused when editing a form, thereby saving save-time in the editor, improving the developer experience, and reducing future maintenance by significantly enhancing the app—does not seem to align with the theory of writing expressions directly in properties like show_if, valid_if, etc."

I wonder, if the theory says one thing (and by theory I mean opinions from the community and even from AI, since I have little reference as an outsider) and practice shows something completely different, which one should I believe, since I am a complete outsider?

It would be great if we could expand on this topic because it affects not only the UX but also the DX (development experience) hahaha.

I often follow your advice: I develop and edit the app with minimal data, and then I update or implement it.

Sending you a big hug—later today I will run some tests and compare save times under identical conditions to see what happens in terms of experience. As an expert, would you support me by sharing any tips you have to improve our experience?

Best regards,
Gustavo

[Aurelien]

I might have mis-expressed my thought.

About saving time, it will depend on the app complexity, hence we can't do lot but be good with efficient expressions and using for example Enum of Ref rather than Ref when [Related XXXs] are unnecessary.

However, about the save/reload time of the preview pane, it makes sense to duplicate the data structure, but with far less data in the DEV datasource.

In the end, here is an example of what I have:

---

@Gustavo_Eduardo wrote:

I develop and edit the app with minimal data, and then I update or implement it.

---

From my understanding, you are already doing that.

[Gustavo_Eduardo]

Yes, dear Aurelien, and I also have this habit of using enums instead of refs when I don't need to. I'm currently testing. If I have to cut down a tree in 5 hours, I'd rather spend 4 hours sharpening the axe and 1 hour with the machine. I'll post comments tomorrow or the day after tomorrow to compare the progress with the community videos.