Zugg Software :: View topic

Newbie Joined: 12 May 2002 Posts: 7

okay, I've got an absolute ton of aliases, variables, and triggers--in fact, it's so bad that zMud stops responding at times because it's backlogged with trigger-processing requests, even on a 2 GHz, 256MB RAM machine. Short of streamlining all my triggers and stuff (and that's a LOT of streamlining ;)), is there anything I can do to keep zMud operating under pressure?

Enchanter Joined: 20 Nov 2002 Posts: 627 Location: USA

Doing complex calculation on a mud that is spitting information at you very rapidly would slow any computer down.
Solution Streamline.....
Give up some come scripts to run more useful ones
or find a way to cut back on the excess calculations.

good luck

SubAdmin Joined: 18 Nov 2001 Posts: 5182

First rule of streamlining: the user is slow then the computer. What this tells you is that you can skip streamlining entirely if your instead shift execution of slow script to periods when user input is being awaited.
Counter to first rule: shifting execution is steamlining.

So what you've got is that by not really improving your scripts themselves, but making small changes in when they preform the more tasking portions you have 'steamlined' them. It is an illusion, but a good one.

In my current script setup, there is only one script that shows me a noticable slowdown, and if I don't really feel like dealing with that then all I do is close my DB window. Then when I want to waste my time I click one button, the DB window reopens and all the stuff that was waiting on me gets done. It really isn't any faster, but looks that way.

As far as actual streamlining is concerned eliminating loops is the key. This is true in every language, even English and assembly. In English if we repeat ourselves it is wasteful, let me say that again (since counter i less is then 3), if we repeat ourselves it is wasteful. You get the point. zScript has provided a number of functions such as %expanddb and %expandlist that can be used to eliminate more time intensive loops, such as #LOOPDB and #FORALL. The key is to be able to take advantage of these in your script. When you can't then go back to the first rule and put the execution of that slow loop someplace you won't really notice.

In general I don't see how you could acheive a state of zMud not responding becuase of script activity, without intentionally putting it into such a busy state. In recent memory tests I built a small script to do just that, and that evidenced that breaking large script blocks into smaller blocks might have some benefit. The specefics of that are untested so you may want to give that a try, then if there is no change just go back.

Newbie Joined: 27 Oct 2003 Posts: 4

quote:
Originally posted by Ledneh

okay, I've got an absolute ton of aliases, variables, and triggers--in fact, it's so bad that zMud stops responding at times because it's backlogged with trigger-processing requests, even on a 2 GHz, 256MB RAM machine. Short of streamlining all my triggers and stuff (and that's a LOT of streamlining ;)), is there anything I can do to keep zMud operating under pressure?

Admittedly I'm running on a 3Ghz 1MB ram system but I've got zmud doing some absolutely sick calculations in terms of complexity and depth of processing and haven't so much as made the system blink in functioning. I'd really be interested in seeing just what you have that managed to slow zmud down. You could have a situation where there is just one or two things that are really nasty and by fixing them fix the entire setup.