Speed Up Your Macros: Difference between revisions
Line 31: | Line 31: | ||
for() | for() | ||
foreach() | foreach() | ||
Take exactly the same amount of time to roll a 1d100 10000 times. In other words, they're equally fast | Take exactly the same amount of time to roll a 1d100 10000 times*. In other words, they're equally fast. | ||
*Used CIF's stopwatch | |||
==macros== | ==macros== |
Revision as of 07:48, 15 August 2011
Introduction
If you start creating your own framework and if you like the process, then most likely you will get to a point that some of your more advanced macros start to become a drag. MT script isn't the fastest of languages and there are a couple of functions or methods that can really slow things down. Fortunately a couple of users (like Aliasmask) have started testing different methods to speed up there code. Below you can find the results, some tips are based on conjecture others have been throughly tested to be faster. I you find a new faster method, don't hesitate to put it here.
jsons
- try to avoid nested jsons objects (so json object within a json object) objects within a json array is likely better
- when storing a json as a property on a token, try to limit the get/setproperty do it once store it in a local variable and pass it along also into submacros. This also accounts if you're changing a property directly (so without get/setproperty) e.g.:
<!-- this (using get/setPropery) -->
[HP = getProperty(tokenName, Hitpoints)]
[HP = HP-1]
[setProperty(tokenNam, HP)]
<!--is the same as this (changing property directly)-->
[Hitpoints = Hitpoints - 1]
- it might be the case that converting (using encode()) a json to string and then storing it on a token. Retrieving it using decode()
- if you want to store a huge and complex json variable temporarily on a token, don't use a property but use token.gm_name (or token.label or token.name) to store it (using a lib token for that). It goes without saying that this is a bit a of an extreme method i.o.w. a hack. If you were to e.g. use the token.name variable on a lib token, interesting (that you don't want) stuff will happen
functions
Nested functions
Try to avoid nested functions so
<!-- Do not -->[h: cleanVar = replace(lower(myString),"[^a-z]","")]
<!-- But do -->
[h: cleanVar = lower(myString)]
[h: cleanVar = replace(cleanVar,"[^a-z]","")]
Loop speeds
The following loops: count() for() foreach() Take exactly the same amount of time to roll a 1d100 10000 times*. In other words, they're equally fast.
- Used CIF's stopwatch
macros
When getting arguments within a UDF (user defined function)
<!-- Slow -->
[h: var1 = json.get(macro.args,0)]
[h: var2 = json.get(macro.args,1)]
<!-- Faster -->
[h: var1 = arg(0)]
[h: var2 = arg(1)]
Notes:
- If you use the macro() function you can only make use of the macro.args method (the slow way).
- This method doesn't work the other way around, if you set macro.return within a UDF you cannot use arg(0) from within the function you called the UDF from. E.g.;
<!--after calling some UDF:-->
[h: doSomething(var)]
<!--this works-->
resultOfDoSomething = macro.return
<!--this won't-->
[resultOfDoSomething = arg(0)]
<!--actually most likely it will 'work' but it won't contain the value you want -->
Tokens
Though this isn't really about macros, it is about speed. What you put in your tokens will also effect the snappy-ness of the game play
- having a lot (guesstimation >100) of macrobuttons on a token will influence dragging it on the map (slow it down) Note: this issue has been partially fixed in MT by Rumble around b70-75. It still has impact on speed, but not by a long shot as much as it used to be.
- having a token with lots of data stored on it, will effect the update of movement of a token on other pc's connected to the server
- large image on a token will also influence speed, try to keep them at 200x200 pixels or lower.
--Wolph42 08:52, 12 August 2010 (UTC)