How costly to CPU/cycles are macros in Twine?

Question

Kind of more of an open-ended question/discussion, so I'm not expecting a "best" answer, per se, I'm just curious to hear the opinion of people with more experience.

We hear a lot about how improper use of set/overuse of $variables can bog things down unnecessarily, but HOW bad is it really?

How many variable changes do you need in a passage for the enduser to notice something is going on? Looking at objects, is there any difference to the engine resolving <<set $var to $var2>> versus 20 individual <<set>> calls that individually set the values of $var to var2 (i.e <<set $var.name to $var2.name>>)?

Stuff like that. Does anyone have some solid feedback on performance impacts, past "don't do dumb stuff"?

Answer 1

From my limited knowledge:  

1. Set macros are not really the problem with story variables. The problem is that a new copy of the entire variable store is created for each new moment in the State history. This means that the number of variables in your story is far lower than the number ultimately being tracked by the State; if you have an unlimited history (the default on SugarCube, though this can be changed) and you have a story that has 1000 variables and 1000 passages, then by the end the State is tracking potentially 1,000,000 variables. Using temporary variables and setup variables can alleviate this. Limiting the State history, if possible, can also help immensely. 
2. Macros are a wrapper for functions: the parser encounters a macro and translates it, the macro definition itself contains a function that is then fired. Macros are always slower than functions, because they are just abstractions of functions. However, this slowdown isn't tremendously noticeable, even in passages containing a great deal of code. 

Setting object properties one at a time will be slower because a single set is parsed once and evaluated once. That said, your provided example code is not equivalent, since the first set passes the object in $var2 by reference, while the second example passes its properties by value, so you wouldn't want to use one in place of the other anyway. 

Comments

Maybe I don't understand State properly, but is there any reason NOT to limit state history drastically with settings IF you aren't using it (i.e you disable back buttons, don't reverse state, etc)?

---

No, that's correct.

If you aren't using the history system, the Config.history.maxStates property should be 1 in every circumstance I can think of.

This still doesn't necessarily mean it's a great idea to go nuts with variables, but it should prevent any noticeable slowdown on most browsers, as far as I know.

At that point, making your game more efficient is a good idea, but not necessarily going to have a heavy impact on performance. A smaller variable store also helps limit the size of saved data, meaning more reliable caching, especially on mobile, and faster download/upload of imported and exported saves for users with slower connections.

It's also a good practice to be in if future projects you make require the history system.

---

Thanks, that's a load off. Regarding passing objects as reference... it being a bad idea, are you referring to its use in custom functions, or something else? Is there any practical reason you wouldn't want to pass an object as reference in normal set macros (i.e custom functions are not a concern)?

---

It's not a bad idea. You just don't want to pass by value when you want to pass by reference and vice versa. I was just pointing out that they're different things used to do different things.