Speed questions on some functions (if's, scripts, and sequence numbers)

I use a relatively slow computer, so speed in processing of any statements or variables is usually a pretty touchy issue for me. I'm wondering about how long processing a variable's contents takes. Here's what I mean:

if world.GetVariable("weather") = "rainlightning" then

vs.

if world.GetVariable("weather") = "rl" then

vs.

if world.GetVariable("weather") = "2" then

Out of the three possibilities, are there any significant differences in speed? Does downgrading the variable contents from "rainlightning" to "rl" or "2" (or "r" or an equivalently small number of characters) make much of a time difference when the if function is being processed? I'd have a large number of these "if" statements, so even a small difference would probably build up for me.

Also, does MUSHclient experience much slowness when dealing with numerous (as in upwards of 30 or so) elseifs and nested ifs in one script? If it does, is there any method around it?

As another question, when does using a script file rather than the "send to: script" function become a better idea? Most of the scripts I have are pretty small, being usually 3-10 lines or so. However, a few are fairly giant in comparison. So should I use all script functions via a script file, or is it fine if I just do that with the very large ones?

Finally, when setting the sequence number, how low should I go? If there's one trigger that pops up far more frequently than most others, should I set it at a sequence number of 90, or would 99 suffice when everything else is 100?

I apologize if these questions are somewhat vague, as I have a habit of sometimes being like that. Just yell and throw stuff at me if you need me to clarify something. Thanks for any response.

The difference between the three examples you provided is probably bellow the minimum precision of your computer's clock. In other words - they are the same. Timing things isn't hard. Though Vbscript only has the Timer function, which to tell the truth can't measure crap, you can still do it. The problem with Timer is that its' precision is too low, so it simply doesn't register anything faster than maybe 0.0001 seconds, and maybe not even that. To go around that you need to time long running loops. For example, if you wanted to time how long assigning a value to a variable takes, you'd do something like this:



That will also work for timing actual functions that you use in your script. For example, to time how long 100,000 calls to your function that does something usefull take you could replace the assignment inside the loop with a call to that function, passing some valid but useless arguments to it if it needs them.

As for whether to put script into the trigger or make the trigger call the script... Large things should go into the script file, small things can go into triggers. But you need to have an idea of what large and small mean for your computer in terms of time duration. Often times when trying to speed things up you gain very little in speed, but loose a lot in code prettyness. It's important to know whether whatever optimisations you are planning are really worth it.

Which brings us to the triggers part. It doesn't really matter whether you use sequence 1 or 10 - sequences just tell the client in what order the triggers should be matched, and there are a lot of those sequence numbers just in case you need a lot of them, I guess. When optimizing triggers, you need to keep in mind that bringing a single trigger down in the sequence (giving it a lower sequence-higher priority than the rest) can yield greater results than prioritizing all of your triggers into levels. The trick is to find the trigger that matches most often. A good example of a perfect candidate for optimization for any MUD is the prompt trigger - that one fires all the time, and if you give it sequence 1 and make it block all other triggers, it can result in well over a 50% gain in performance, considering that prompt lines consitute up to 50% of all MUD output and you might have hundreds of triggers matching on every line. If you further optimize the trigger itself by using a regular expression that stops matching very soon if it encounters an invalid line, you can get even more speed out of it.

Much thanks for the info, Ked. It's been very helpful so far.


If I may tack on another couple questions:

Are multi-line triggers significantly slower than single line triggers? Should I stick with single lines whenever possible?

Does the timer granularity only have an effect when a timer has been activated? If I set it to 0 seconds, will the program be slower at all times, or only when a timer is running?

Thanks again to anyone who can answer this.

Differences in speed in situations like these are usually not significant if you're doing it rarely, even if you do it once a second. To really feel differences, whatever it is has to be truly long or be run very frequently.

I don't think timer granularity matters if no timers are being run, but that is an implementation detail and only empirical testing or Nick could answer for sure. Same for multi-line triggers - it all depends on how Nick did them. My guess would be that in the latter case, the difference is not significant and in the first case, granularity does not matter if no timer is being run.

Out of curiosity how slow is this 'relatively slow' computer? A handful of if statements on string variables even if run many, many times a second really shouldn't make a huge difference at all. Even sub-Pentiums e.g. 486s probably wouldn't see much of a performance hit.

Thanks for the info, Ksilyan. Also, you were correct about there being a negligible difference. So far I've loaded MUSHclient with many triggers, and differences in speed are still very minimal in my opinion. The effect that shortening a few variables would have is rather small as I see it. Overall, it's a stark contrast for me when I compare it to the client I used to use. Kudos to Nick Gammon in that regard.

Ked, the problem with your example:



is that the loop setup time might swamp the time taken to do the assignment. In other words, you are timing loops themselves.

You are right that if you are worried about time you should use a script file and not "send to script". The reason is that "send to script" is compiled (interpreted) by the script engine *every time* rather than once, which is what happens when you use a script file.

However with small scripts, and if they are attached to a trigger that fires infrequently the difference may be negligible.

Another trick would be to use regular expressions in trigger (simply click on "convert to regular expression").

If memory serves me correctly, MUSHclient does the conversion from non-regular expression triggers to regular expressions on-the-fly for each trigger (at present) which is a little inefficient. The conversion is quite quick, but if you are trying to save time, I would do that.