Zugg Software :: View topic

Newbie Joined: 12 Dec 2001 Posts: 4

As my collection of triggers has increased, I have noticed a very clear drop in zMud performance (using 6.40 at the moment). This usually manifests itself in cases when loads of text come from the mud in a small period of time (checking scrollbacks, fastwalking etc). When the slowdown happens, zMud gobbles up loads of CPU and freezes anything else on my desktop.

Does splitting triggers into separate files and loading them when needed improve performance?

Does disabling triggers help in performance issues?

Is there any guide on writing efficient triggers which would contain the "do's and don't"s of zMud pattern matching (like avoiding too greedy pattern matching operators etc)?

Adept Joined: 11 Nov 2000 Posts: 228 Location: USA

Greetings,

To test to see if triggers are the problem with the slow down, ZMud has a little tester function built-in.
If you shut off triggers (the gun in the corner, next to the clock) and type CTRL+Q text will be put on the screen as fast as zmud can put it. A time is displayed on the status bar.
So try this a few times without triggers enabled find the average. And then turn the triggers back on and hit CTRL+Q a few more times.. If the numbers are say... very different (I get 15.5 avg) then let the board know.. Plenty of tricks and tips you can do to make your triggers more efficent... (no time to post now.. but im sure others will)

Hope this helps :-D

zMud 6.40; Win2000

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Disabling triggers does help. zMUD doesn't even try to match agaisnt disabled triggers so it should help a lot.

Also, the most effective trick to speed trigger matching is to make sure your trigger contains as much fixed text as possible. That is, try to avoid triggers that only contain wildcards or wildcards plus a word or two.

Finally, try enabling only a group of triggers at a time to find out which ones cause the most slowdown, then work on optimizing those.

Kjata

Newbie Joined: 12 Dec 2001 Posts: 4

Thanks for the tips,

I tried the CTRL-Q test a couple of times with and without triggers enabled.

Without triggers, on average the score was 1.8
With triggers enabled, it was around 13

So there was a clear difference. Whether the scores are "good" or "bad", I have no idea.

I do have many triggers that use greedy wildcards like *. I have tried to disable those classes that I don't need but it doesn't really help much.

I would not be so concerned about this, but the practical effect of the slowdown is that when I get loads of stuff from the mud, the end part of it doesn't show on the screen at all, the text flow on the mud window just stops and the rest of the mud output is lost. This means that when speedwalking etc, I have to manually "look" at my destination, because I cannot see the end of the speedwalk output.

Some info on my system:
-512k/256k ADSL connection
-Athlon 1.4Ghz CPU
-512MB memory
-.mud file size: 183kB

Another question, by the way:

How do I store patenthesis chars inside variable strings properly? If I write the following statement with the editor, it gives error messages from the ('s:

#VAR status {SPELL X (on from %time( hh:mm:ss))}

If I use the "quote" special char ~ before the ( in the following way

#VAR status {SPELL X ~(on from %time( hh:mm:ss)~)}

the error goes away, but then the special char itself is also included in the string.

The reason I ask this is that I also have a nagging feeling that I have old triggers that may be giving this error and to my logic, an erroneous trigger is also a slower one.

Thank you for any ideas.

--
In a world of compromise, some don't.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

For the variable, use %concat:
#VAR status {%concat("SPELL X (on from ", %time( hh:mm:ss), ")")}

Kjata