What method do you guys use to test the speed at which your system runs?

If I want to see how competant my system is, I jump in the arena with Thorgal, aslaran Knight, and have him hack away at me. It's a random 1-4 afflictions a round.

Or me, quite soon. Aslaran knights can test your system reeeal nice.

Zmud seems to be the fastest too. There was once an update that made triggers 500 times faster.

That update only works if you use Trigger states, as far as I can tell.

Trigger states?

Yeah that was my responce to it. Theres a link out there somewhere, but I don't want to seem like I know anything I don't so I'll let the people who informed me about it, inform you.

@Richter:
Trigger states means triggers that basically have multiple patterns, which can be matched one after the other given predefined circumstances, like, state 1 could be the first line of an attack message, state 2 the second line of the message with the limitation that state 2 only fires if its line comes right after the line that fired state 1. If that makes any sense *g*
As Daganev said, using trigger states for multi-line matches rather than static triggers with $s in the pattern results in much faster execution, among others.

Generally, multistate triggers are VERY handy, 'cause they're much more flexible than static ones and allow you to do things with a single trigger that would've required a separate class before.

Just try and see, the zMud help should give you a good basic idea what it can do and the the support libary/forums at www.zuggsoft.com give suggestions too.
Or have a look at the ACP, it demonstrates alot of the "modern" zmud gizmos like multistates.

@Lodin:
I sometimes take logs of lengthy spars and feed them into zmud via #FILE and such, and let zMud echo %time at the beginning and end...
That way you can get an idea how the speed of your system compares to other versions of it or other systems.

the thing I read in the help file with trigger states is that a Paramter of wait 5 seconds in a multistate trigger with no second pattern, can be faster than the #wait command in general.

I know with the #wait command and forging, I still have to pay attention because sometimes the trigger fires off before I have balance back. (I get balance back after 4 seconds and I was being cautious because of lag) but with a multistate trigger that shouldn't be a problem. (have yet to figure out how to do it, thats just what I gleaned from the helpfile.)

If you are using wait to redo something once you have balance then it's always a better idea to actually trigger the "you have recovered balance" line...

Just create a temp trigger or even make some sort of "todo" list that gets executed whenever you have balance. That's a really neat little tool. Not difficult to code too.

Oh and: NEVER use #wait. Just don't. It's bad and it stinks like dead mice.
If you really need to do a delay then there's always #ALARM, which is better in many ways.

why use #wait when you can use alarm. and why use a file to feed to the program when you can CTRL+Q?

Im suprised that no ones mentioned CTRl+Q yet.

oh and by the way, on my athlon xp 1700+ with 1gig ddr2100 i got a score of 1-2 with an empty profile. i then dump the ACP/LCP in there and it goes up to the 60's : )

when i got rid of the affliction triggers in the acp it ran with a score of 4 ; )

what is it about those affliction triggers that bogged things down like that?

With the modified version of ACP that i use in lusternia for bashing purposes, WITH all of my other scripts and trinkets im getting a score of 13.

what about you guys?

I tried the Ctrl-Q and I got no score. Not sure what I'm missing about it that it gives me nothing but lots of alphabet and number lines...

the "score" is a number on the lower left hand cornor, where the status bar would normally be. try to do this while offline so that the status bar doesnt overlap the score, cause if the mud sends you a line that score will get wipped off before you can read it

With what I've got of my LCP so far, my score (offline now, of course) is 37.0. Not the speediest, but I've got a settings file that's about 175k now. Heh.

I did this same test on my ACP (which actually accounts for less than half of my scripts, if you can believe it) and the score was 67.3! My Achaea settings file is 310k.

I'm not entirely sure how much CTRL-Q actually tells you.
I mean, from what I can see it simply times how long it takes to output all that stuff, unless you actually match triggers on those output lines I don't see the point... You don't really want to know how fast your zMud can output default MUD output if none of it is matched but you rather want to know how fast zMud runs if your system actually has work to do... or am I mistaken there?

That's why I mentioned the #FILE, so you can parse combat logs where your triggers get something to work on. Can just copy&paste it too of course but I'd say having zmud pick it up from a file is more convenient.

You'll notice that say.. when you have absolutly nothing in the settings you'll get a score of like.. 1-2. When you have something like the ACP or LCP in there it jumps up to the 30's.

It definitely makes a difference. Before i went and tweaked my settings i was getting a score up in the 70s.. it actually affected my bashing because i was attacking slower and autosipping slower.

#TR {You crush the herbs and mix a red tincture.} {#TEMP {You have recovered balance on all limbs.} {mix red;inr tint}}

Uh..

#alarm lets you be as percise as #wait? It was my impression that #alarm only worked on the whole second

Also, I have many other things going off my return balance message, and I like having that 1/2 second of balance while forging so I can transfer commodities and money to people I'm with in the forge. I use to have it on the balance and found it too restrictive.

Something about cntrl+q... havn't tested it yet, but from what I read about trigger states, is that the next state in a trigger isn't "active" untill the first trigger is hit. This "speeds" up the system, according to the help file. So I can only assume that each line the system searches all the triggers and stuff, so the more triggers the lower that score. However, Trigger states reduce the number of actual triggers you have, speeding up the general search of your system, making each trigger itself fire off faster. I've been wondering if alias with large sequences of commands affects our system speed or not?

I know that my single color trigger which searches 1,212 names bogs down my system (all computer activity) completely every time I try to edit the trigger, but runs with no problems once its been edited. (because of this, I just delete and recreate the trigger each time I want to edit it because it is hell of a lot faster)

@Daganev:
#ALARM creates a trigger, which means you can stop the waiting period prematurely. But you're right #alarm only counts seconds whereas #wait does milliseconds.

I'm not saying that CTRL-Q doesn't tell you anything, it simply tells you how fast mud output that won't match any of your triggers will be displayed. Every one-line Trigger you have will be matched against any single line of output displayed, so the more of those triggers you have active the more slowly general output is displayed. But as I said, matching patterns is not the only speed factor in a system, if you really want to know the speed of your system then you need to give it something to actually work on. Having only few triggers and therefore a high CTRL-Q score doesn't help you alot if those few triggers you have are so utterly complicated that each of them takes half a second to process.

Regarding your coloring trigger, that's odd. It shouldn't do that, unless you actually store all your names in the trigger itself. I think I have the same trigger as you have and I only get a slowdown if I want to edit the variable that contains all the names, which I wouldn't do manually anyway. Just use triggers to auto-update your list (if someone speaks on a channel belonging to the group of people of your list for example) or aliases. The coloring trigger itself shouldn't slow you down while editing it.

-david

Alarms can go to less than a second resolution, but they are only accurate above a half second (i.e., you may not get exactly a quarter-second, if you try, but it'll be faster than a half-second). This only works for "one off" alarms and not for regularly firing alarms.



And if you want it to go off more than once, just have your alarm make a new alarm!



There are many ways (and better ways) to do things with alarms, so play around with them and see what you can do. The articles on Zugg's site are all good reading.