The number is not for recalculations of each individual row — the number is for each “recalculation pass”.
A row is added in the Tasks table that triggers
Tasks.Filter(Project = thisRow) recalculation on a column in Projects table. Regardless of the number of rows in the Tasks table, this will show up as 1x. The time, of course, will depend on the sizes of both tables.
Now, let’s say that column is not just
Tasks.Filter(Project = thisRow) but a more complicated expression that’s dependent on multiple tables and/or canvas formulas, that are also indirectly linked to the Tasks table through a complicated dependency graph:
In a scenario like this, adding a new task:
- Directly affects View of Tasks, triggering the recalculation of this filter
- Triggers recalculation of Users.Last Added Task
- The latter triggers recalculation of the canvas formula ULILastCreatedTask
- And finally, that formula triggers recalculation of the filter once again
It is very much likely (though not guaranteed) that some of the recalculations will be deferred, so the View of Tasks will be actually recalculated twice: first on the change coming from Projects.Tasks and then on the change coming from the ULICastC.T. canvas formula. That’s when you’ll see 2x in your debugger.
Another scenario when you can see this is if you have a
RunActions() that modifies the same row multiple times. You might have written such code for convenience (e.g. your former Flow button which I debugged), e.g. you modify certain columns in the beginning of the formula, then some other columns in the end of the formula. But those are two separate edits, and
RunActions() forces them to be on two separate frames. If each of the edits triggers recalculations of other parts of that doc, then you’ll see 2x not just on the immediate row but also on a) everything that’s dependent on it directly, and b) everything that’s affected by the changes in a).
So, to answer your question about how to apply this — use this information to:
Find places where changes don’t arrive in a single frame and a formula gets recalculated multiple times, first with partial changes and then with the final state. Solution: simplify dependency graph, make it so that changes flow in only one direction and ideally don’t branch and merge.
Find actions that change the state on the same row multiple times within one
RunActions() and rewrite the code so that all changes are applied at once in a single ModifyRows.
Of course, not all 2x-3x-5x calculations are worth the effort if they run in mere milliseconds anyways. They can trigger excessive recalculations in heavier formulas though, so it may still be worth to check on them.
I’m not a Codan though, so I guess my answer is not reputable enough either. I’ll try to get some engineer’s attention to this thread, however I have a feeling that it’s something that only few engineers would 100% certainly know of.