Performance hit: dynamic variables vs additional measure

[rxtd]

I have a lot of values that are changed by script. I use them in String meters.
Script is used on every update.
As far as I know, there is no difference between setting DynamicVariables=1 and using !SetOption bang — since values change every update, DynamicVariables=1 is effectively set by the bang.
The only thing that changes is a text of a String meter. No other option is affected.
Despite performance hit of DynamicVariables=1 is not that big, I have about 150 String meters which values are set this way, so I think that removing this option can improve performance of my skins.
I consider using String measures instead and making String meters obtain values from them but I'm not sure if using more measures will not counterpart performance benefit.

Can anybody say what is better?

[khanhas]

I would say !SetOption

DynamicVariables=1 forces meters, measures to re-read every single option value then find/replace variables in every update. I think that would affect on performance a lot with your massive amount of meters.

[rxtd]

Hi, khanhas
!SetOption bang enables dynamic variables for one single update. If I use in in every update, dynamic variables will be effectively enabled even if option DynamicVariables was not set on a meter.
Actually, it can decrease performance as not only variables will be replaced but bangs will also be executed. It probably won't make a noticeable difference, but still.

[Brian]

As far as I know, there is no difference between setting DynamicVariables=1 and using !SetOption bang — since values change every update, DynamicVariables=1 is effectively set by the bang.

SetOption will temporarily set DynamicVariables=1 on the object (meter or measure), causing that object to re-evaluate ALL of its options - not just the option referenced in the SetOption bang. This happens only on the next Update cycle, and when the "real" DynamicVariables option is re-read, it is changed back to its previous value.

I consider using String measures instead and making String meters obtain values from them but I'm not sure if using more measures will not counterpart performance benefit.

This will just depend on how you are setting things from your script. I would say that re-evaluating a String measures options would be more efficient than re-evaluating a String meters options.

Example 1:

Code: Select all

;Script that manually sets some values to each string meters Text option via SetOption
[Script]
Measure=Script
ScriptFile=something.lua

[Text1]
Meter=String
Text=

[Text2]
Meter=String
Text=

Example 2:

Code: Select all

;Script that manually sets some values to each string measure String option via SetOption
[Script]
Measure=Script
ScriptFile=something.lua

[mString1]
Measure=String

[mString2]
Measure=String

[Text1]
Meter=String
MeasureName=mString1

[Text2]
Meter=String
MeasureName=mString2

I would say Example 2 is more efficient since the String measures only have 1 option (plus the general measure options), and would update faster than Example 1 because each String meter has a lot of more options to parse. Example 2 will only grab the new text from the measure when it updates.

-Brian

[rxtd]

Thank you for you answer, Brian.