Solved: Disabled (expensive) Format-rules vs performance

Swoopy · 11-17-2020 04:43 PM

Do disabled (expensive) Format-rules still affect performance?

Is it better idea to delete them?

pravse

@Kirk_Masden — very good guidance from you to treat “rendering performance” or “interactive performance” in a different category from sync performance.

Rendering performance is really about what we ask the device/browser to do when a users taps on something or scrolls something. The processor on a device is slow and if you ask it to do a lot of computation, it will make the UI feel “sluggish” (takes a noticeable time for a UI response). Expensive format rules fall in this category, as do expensive searches, as you point out. Also, if you had a very large data set and open a view on it, it could be slow if all the data has to be processed in some way (still, the example you had of a view with 8000 records feels odd to me).

If a format rule is disabled, then it is not computed and therefore there is no impact on interactive performance. Now if your app had a thousand disabled format rules (for no good reason) then it will probably need more memory resources, the system would loop through the thousand rules, check each of them and decide they are not to be applied, etc. So some overhead for a pathological case like that but not in the normal cases.

View solution in original post

Kirk_Masden

I wish someone had responded to this. I too am interested in this topic.

Swoopy

My workaround is to play-safe by removing them and save their expensive expressions for reference.

Koichi_Tsuji

Format rule is surely slow donw the performance. I could not find my previous post reporting about this.

when the app is rendering HTML to generate app view, the app formula is evalulated to apply format rule such as color etc. This is just CSS stuffs, so it is affecting the rendering process. I confirmed with this AppSheet dev team before.

So best practise is not to push too much format rule to the view if we want to ensure the higher performance (rendreing view) on html.

@Takuya_Miyai

Swoopy

Thanks for the info.

However, this topic is “[Disabled (expensive) Format-rules vs performance]”.

Generally we all know that the expensive rules affect app performance. But what if we disable & keep them, would they still affect the app performance.

Koichi_Tsuji

Ah, okey I got your point now, thanks.

Kirk_Masden

Hi @Swoopy ! I found this:

I’m not sure if I have a complete understanding of what @Phil is explaining here but I guess one take away is that the difference between a format rule being disabled and being deleted would be negligible in terms of the time it takes to read the rule into the device’s memory. I assume that also means that a disabled rule with an expensive expression would not cause a problem for performance but I would appreciate it if someone could confirm that.

I’d like to point out that there are two kinds of “performance.” One has to do with sync times. This is what the “Performance Profiler” helps us with:

The performance profile helps you understand and tune the performance of sync operations

But sync time is just one aspect of performance. As this comment from @praveen indicates, “display/rendering” is another:

I think the distinction that @praveen is making between two kinds of performance (sync vs. rendering) is very important. However, my impression is that the two types are usually not distinguished in this community. Take this quote from @Adam:

Of course, @Adam is correct, but the kind of performance he is referring to is “rendering” not “syncing.”

When an app performs sluggishly on a device, it can be hard to figure out what is slowing things down. I came to this post of yours today because an app of mine was very slow in table view. I could view it but resorting columns by tapping on the headings was very slow. I thought my format rules might be the problem so I disabled them but that didn’t work.

What did work was @tsuji_koichi 's suggestion to reduce the number of columns that could be searched. (Thanks Koichi!) Another change I made that had a big impact was to delete an extra view that displayed the same 8,000 or so records. Fortunately, I didn’t need that view (I just made it as a sort of test of another way of constructing the view). It was interesting to me, though, that deletion of one view could have a significant impact of rendering performance.

So, all of this is making me think that it would be nice if AppSheet could improve its performance tools by adding a “rendering” category. Also, I’d like to suggest that discussions of performance in general distinguish between syncing performance and rendering performance. I’ve been getting some very useful help regarding performance from @MultiTech_Visions, @Marc_Dillon , @1minManager and @Steve recently. I wonder if they have any thoughts about how important / unimportant it is to distinguish between syncing performance and rendering performance.

Swoopy

Thanks.

Because we don’t know the mechanism inside AppSheet engines.

Case#1: Disabled (expensive) rules are not loaded at all, they don’t affect anything.

Case#2: Disabled (expensive) rules are always loaded into memory & just sitting in background, they wouldn’t affect anything.

Case#3: Disabled (expensive) rules are always loaded into memory & processed in background, they may affect something.

Kirk_Masden

I think that Phil’s comment means that they are loaded, so it’s either Case #2 or #3.

Koichi_Tsuji

1minManager

My thoughts on this are that if as @praveen said they only affect rendereding then unless there is obvious rendering isses then just leave disabled. If it is causing issues then what I would do is to document then delete the 2-3 most intensive ones and see if that cures it.

pravse

@Kirk_Masden — very good guidance from you to treat “rendering performance” or “interactive performance” in a different category from sync performance.

Rendering performance is really about what we ask the device/browser to do when a users taps on something or scrolls something. The processor on a device is slow and if you ask it to do a lot of computation, it will make the UI feel “sluggish” (takes a noticeable time for a UI response). Expensive format rules fall in this category, as do expensive searches, as you point out. Also, if you had a very large data set and open a view on it, it could be slow if all the data has to be processed in some way (still, the example you had of a view with 8000 records feels odd to me).

If a format rule is disabled, then it is not computed and therefore there is no impact on interactive performance. Now if your app had a thousand disabled format rules (for no good reason) then it will probably need more memory resources, the system would loop through the thousand rules, check each of them and decide they are not to be applied, etc. So some overhead for a pathological case like that but not in the normal cases.

Kirk_Masden

Thank you very much, @praveen and @1minManager ! I’m starting to think that my Android device might be the problem. With 8,000 records, my app works quite nicely on iPhones (even an old iPhone 6) but can be sluggish on my LG X5 (2018), which doesn’t have very high performance ratings:

I’d like to ask one last question regarding rendering vs. sync performance. I’ve learned to be wary of virtual columns. I know, for example, that virtual columns with expensive expressions (e.g. SELECT(), etc.) can be problematic. I wonder, though, about how best to handle simple text onto which I hang inline actions, such as hyperlinks. To improve performance, I’m currently converting a number of hyperlink virtual columns, in which each line constructs a different URL based on the word in that row, to actions in which the URL constructing expression is in the action itself, not in a virtual column. It’s my understanding that this will be better from a performance point of view (syncing and rendering?). The question I have now is Can I use virtual columns for the text onto which I hang those inline actions? The text is extremely simple – something like =“Longman Dictionary of Contemporary English” and repeated, without variation, 8,000 times. Of course, it’s quite easy to put a consistent line of text like this in a real column, but I wonder if it really is a good idea to fill my sheet up with such real columns that each have 8,000 copies. If getting rid of the virtual columns in this way is a good idea, I wonder if I will be doing it primarily to improve sync performance or if it will have an effect on rendering performance. Thanks!

Swoopy

This is very clear explanation.

Thanks BOSS.

pravse

Hi @Kirk_Masden, you should never have a virtual column that is just a constant. That will just bloat your data with 8000 copies of that text.
I’d suggest you just put that text into the place you want to use it (inside the action constructing the URL)

Swoopy

In some case I myself decide to use this practice as workaround (have a virtual column that is just a constant/or another copy of related column such as [Column’s name] in the virtual column’s expression). The reasons is just to change the column’s display names on table views (normally make it shorter than in the detail/form views).

You would suggest using CONTEXT() to control the display names of the real-columns (not having the virtual columns). This is okay if there is no in-line action bound to it because if there are in-line actions bound to the real-columns, they are shown on related table views and cannot be hidden.

I’m not sure if this problem is solved yet. I used this practice a long time ago.

Related topic

Kirk_Masden

Thanks again, @praveen ! I’m sorry to bother you but I’m still confused. I’m using inline actions for my URLs:

Earlier, these actions began as virtual columns but after getting some expert advice I was convinced that I needed to take the URL constructing expressions out of the virtual columns and put them in actions.

(Note: There’s an interesting comment from @MultiTech_Visions immediately after Steve’s comment about AppSheet sample apps not following best practices. If you haven’t seen it, you might want to ready it.)

So far, so good. The problem is that I think I need a column to attach the action to. So, I thought my only choice was between either virtual or real columns. Is there a third approach? If not, should I go with real columns?

P.S. Here’s what the links look like in my app:

Each link looks up the key term (“curate” in this case) in the named dictionary.

Currently, the “English Japanese dictionaries” heading (and headings for other categories) are virtual columns. Perhaps I need to make these real columns.

pravse

Hi @Kirk_Masden , ok I understand. Your question really isn’t aything to do with actions, I think.

You need some column to attach inline actions to. So you are creating some virtual columns just so that there are appropriate attach points.

I suppose if you really want a lot of inline actions, then that is what you need to do. Whether those are virtual columns or physical columns, it doesn’t really matter. If the same constant values are being repeated 8000 times, it is a waste of memory, network bandwidth, and also a bit of virtual column computation (even tho it is just constant expressions).

We do have the concept of “Show type” columns that are just for presentation but not actually in each data row. That’s what you normally use for section headers, etc. I don’t think we currently let you attach actions to them (this is the first time I’ve seen a possible case for it). Have to think more about it

Kirk_Masden

Thank you very much for your response. Now I understand what I need to do to finish my app.

I took another look at the “Show type” column. It has a useful URL category that works well. Unfortunately, as you indicated, I can’t attach actions to such a column. Also, the appearance is somewhat different from an ordinary column (the text is turned blue as in HTML, line spacing is different, etc.).

For now, I think I can depend on the processing power of most devices to overcome certain inefficiencies that will remain in my app. If, however, a day comes when we can click on a button and make virtual columns “Show only” (cannot be referred to in expressions, etc) I think that would make the AppSheet platform that much more powerful. Or, the current “Show” type could be expanded but, if that happens, I hope the column will be visually indistinguishable from ordinary virtual columns.

As always, I appreciate your taking the time to consider my rather unconventional uses of AppSheet.

Fabian_Weller

Another use case: Instead of showing the Action, use a Show Type VC and attach the Action to it.
This is possible with Text Column type, but not with Show column type.