|
Mud Master and Speed A post on MM's board got me thinking to write this up. I'll address, as basically as I can, how MM works (mostly related to actions) and how to optimize scripts to save unnecessary burden on MM. First a quick primer on how MM parses/operates when text comes in from the mud. 1. Text arrives, MM snatches it up (you've yet to see it) 2. The text is checked for action matches. 2a. If there's a match, the action is run until all commands in the action have been completed. 2b. Assuming /multipleactions is on (which it is by default with later versions of MM), MM then continues searching for more action matches and runs any other actions to completion. 3. Gags are checked. 4. Highlights are checked. 5. Subs are checked (I assume MM skips this if a gag was found for the string). 6. Text is; printed to the display screen, gagged, highlighted and/or substituted. I'll kinda of jump ahead here for a sec... Substitutes are incredibly slow to process MM is heavily burdened with finding exact string matches and replacing them, aka substitution. I strongly recommend just not using substitutes -- you can easily substitute text by using gags and actions with /showme's. Plus a gag+action "substitute" is a lot more configurable (colors, text, if's, etc). I have little doubt that a gag and action with showmes is faster than a sub. Subs are just plain slow to process. As well, gags are a bit intensive for what little they're doing. Try to be sparing with gags. Personally I tend to use a good amount of gags, as I hate all the default spew the mud sends. (see below about enabling/disabling stuff). Gags definitely process faster than subs, but add more parsing before the next line of text coming from the mud is processed. Using wildcards with gags (or subs/highlights) will decrease the process speed as well. Use wildcards (%0-%9) sparingly if possible. I find Highlights to be pretty lame since the ansi procs went into MM. They're just one more step of parsing that you really do not need to burden MM with. The fewer actions, the faster the parsing. MM checks ALL actions against the incoming text string (with /multipleactions on). Less actions naturally means faster parsing for the specific string. If at all possible, combine commands for your multiple actions into 1 action. Although this can be a pain with huge actions. Example: /action {Joe says, '%0'.} {slap Joe} /action {Fred says, '%0'.} {wave Fred} ... /action {%0 says, '%1'.} {/if {$0=="Joe"} {slap Joe} {/if {$0=="Fred"} {wave Fred}}} {} Handy for small actions, but a pain with larger ones. Disable and Enable whenever possible I try to make a habit out of "smart" actions, gags, subs. "Smart" meaning they turn themselves on and off, as needed. For example, take the "where" list in my OmaSpy script. I only need this action running when I actually use the where command. This not only saves some MM parsing time, but saves storing info that might otherwise "match" the action (like "who" might). When one does "where", you get like "Players in the vicinity:".. to me that means "turn on the action!" After the where list you naturally get your prompt, and that means "turn off the action!" /act {^Players in the vicinity:} {/enableaction {[%0] - %1}} {} /act {<%0hp %1br>} {/disableaction {[%0] - %1}} {} /act {[%0] - %1} {do a lot of stuff} {} An even better method would be to enable it via an alias, then disable via alias (or action to automate it). /al {wx} {where;/enableaction {[%0] - %1} {} ..thus I saved 1 action! 2 Actions if I disabled it via another alias. Disablegroup/Enablegroup are great commands as well. You can quickly disable/enable a group of actions (or any other command in the group). I tend to use this quite often. Say I'm making a script "OmaSpew", I'll group the actions as "OmaSpewActions" so that I can quickly disable that group when I'm not using the script. Disabling anything other than actions, highlights, gags, and subs, really has zero affect on MM's parsing speed. So when disabling, concentrate on those 4 at the minimum. Short as Possible The shorter the action, the faster it parses, and the sooner the next line of incoming text will get processed. Some commands/procs are slower to work than others, @WordColor() is notorious as a "slow" proc. @CharColor() is a lot faster. Think of it this way: if MM has to figure it out, it's taking longer. @WordColor() means MM has to figure out what is a word, then the color of that word. While @CharColor() all MM has to do is find the color of the given character. @TextColor() is fast too, MM simply has to find the color of the given string. Of course "slower" commands/procs is kind of relevant, seeing we're talking milliseconds, but in a big script it is noticable. When using ifs, put them in logical order (see my if tips). What is most likely to be true should be up front so the if is processed quickly. |