In Workshop, when I display a variable 2 (e.g. a string variable in a metric card) that is coming from another variable 1 (e.g. an Object Set variable, aggregated to a string) in a metric card:
Is the variable 2 computed when the metric card is shown on screen ? Or is it computed when variable 1 updates, even in the background ?
Hi @VincentF there is definitely some smart logic that variables are only calculated if they are visible for the user.
Here one very simple example. We have two metric cards, where one is always visible and the other is in a tabbed container.
The input strings to the metric cards are simple str-concats of static strings just like this:
Now we run the performance profiler in two different scearios:
the tabbed layout starts with “Metric Card Visible”. As expected we see that both variables are being fully calculated.
in this case we default to the “not visible” tab and we see that only the always visible variable is calculated.
Only onceI switch the tab to “Metric Card visible” it also calculates the second variable. See here that I switched ~2s after the profiler started the tab and we see the second variable being calculated (dot is very small in timeline chart)
Knowing about this hehaviour that workshop “only loads what’s visible”, you have a pretty good lever to tune the performance.
Note: One observation I had is that I am not entirely sure if this behaviour holds true for all types of variables. Or meaning more the nature of a variable. I sometimes had the feeling, that especially function-backed variables are more often calculated although I would not expect them to be. However, this might also be due to the complexity of variable flow in the application where I observed it.
This is correct, variables in view mode (and in edit mode when the performance profiler is enabled, to mimic the view mode behavior) will only “automatically” recompute if they are directly, or via a downstream variable, used in a visible widget or layout.
This is true of all variable definition types! You may see a function backed variable execute more often than expected if it is somehow used by a downstream variable that is used by some visible widget or layout.***
The variable “recompute behavior”, available on variable definition types that may require async calculation, can be used to prevent this “automatic” (default) recompute behavior, in favor of more explicit recompute strategies which you will be responsible for triggering via recompute events when needed.
***Edit: there is a bug that has existed since Workshop introduced this “lazy variable evaluation” behavior where all variables backing layout state are considered visible, even if the layout is entirely not visible (and not just hidden due to it’s own conditional visibility variable hiding the section). This seems likely to be the cause if you notice extra functions executing.
