Zugg Software :: View topic

Newbie Joined: 29 Jul 2007 Posts: 7

I have no clue why but on my computers Zmud was slow and Cmud is even slower. I have no clue why or how this is caused. I can't believe it is the client for nobody else seems to have the problem. I cant believe it's my computers either because hey... MUD's are nothing but text. Let me give some details and examples and lets hope anybody comes up with ideas to tackle my problem.

I use zMud and CMud to play the Achaea MUD. I have 1000 Mhz Athlon desktop PC with 512MB RAM and a HP Ombibook laptop from the same league (1000Mhz / 512MB RAM). They both have the same problems while running the MUD clients.

Examples:
1) Achaea has an option to switch of server side linewrapping. When i switch of the server side wrapping and let Cmud or zMud (makes no big difference) do the wrapping. A piece of text counting 10 lines would take over 5 seconds to be wrapped by these clients.

2) When in a 1 to 1 battle (nothing special, shouldn't give any flooding trouble) CMud rather quickly decide that things are to much and although it slowly keeps processing the incomming data and firing triggers and stuff it kinda shuts of the command line.. letting me give in commands at a speed something like 1 character per 3 seconds, which makes it impossible for me to do anything but sit back and watch what happens.

Everybody keeps telling me that it's weird that it's that slow and that it should not be. I have no clue what may be causing this problem but I need to find a way to solve it. So if anybody has the slightest idea what may/can be a possible cause please let me know so I can check if that is the case over here.

All ideas are appreciated, thanks in advance.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Chances are that you've got scripts that run rather slowly. When you disable triggers, do you still see text scrolling very slowly?

Newbie Joined: 29 Jul 2007 Posts: 7

Nope turning off all triggers makes speeds up things indeed. But that is not a solution for my problem because it creates an even bigger problem Cool

Larkin I know you have quite some wisdom how things work behind the scenes. Maybe you can give me a list top 10 list of things that are slowing down scripts. So I can use that list to improve / speed up my system.

That would be a great help because I am starting to fear that there isn't one stupid little thing that I forgot to switch of in my settings that will solve everything.

Posted: Sat Aug 04, 2007 1:21 pm

If turning off triggers speeds things up, though, it tells us how we can help you fix it. And the way I'd suggest you fix it is this: Use fewer triggers, and most especially, streamline triggers that fire very often.

The most obvious one I can think of is a prompt trigger that has a buttload of #if checks in it, a la ACP and Acropolis. You can move the code that those #ifs fire into events and use an OnPrompt event to call them. Then, instead of setting the variable that'd change the #if (like HaveBalance or CanDrinkPotion or whatever), you just disable and enable the event. It saves time because the event is just ignored if it's disabled, and there are fewer database checks on the variables.

My list of Top CMUD Slowers would be too many triggers and too many stringlists, probably in that order. String list operations are slow, especially %ismember and %sort. Writing lots of items to a list all at once is also pretty slow in the current version (but should be much faster in the next version with some caching).

Running craploads of triggers is by far the most common cause of this though. It's normally that people have a ton of triggers that send the same command or set of commands and can probably be optimised.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Well, if turning off triggers gives you back your speed you can start by turning off all of your classes at the root level and re-enabling them one at a time until you have found the culprit.

Loops in scripts can cause this behavior if they are looping through large databases or string lists.

Using a lot of (*) to capture everything when you are just going to throw away the result without doing anything with them in your scripts.
In fact if you ARE using the result the odds are you could use a %w, %d, %a, %n %s, or their regex equivalents. A range [a-z] [abcefidz] or a possibility list {Could be this|Or that}.

If you are not going to use the last part of a line then you can just leave off the match altogether. An example.

So and so snaps his fingers before the eyes of a big black dog.

Someone might do this to match it.

^* snaps * fingers before the eyes of *$

While this is all you need for this trigger.

snaps {his|her} fingers before the eyes of

Posted: Sat Aug 04, 2007 5:50 pm

I just thought I'd expand a little on why Arminas' last suggestion is such a good one. CMUD uses the regex engine for its triggers (even the Zugg pattern syntax ones). The way regex handles the "^*" at the start of the pattern is by defaulting to greedy mode - that is, the star will match as many characters as it can. The pattern moves through every character checking to see if it matches the star (and of course it does). Now it's reached the end of the string, and the star finally stops matching and it moves onto the space. The space doesn't match the end of the string, so the engine makes the star "give up" its matching characters one by one from the BACK of the string until a space is received. Then the regex moves onto the s, which probably won't match again, which causes the engine to start backing up again, and so on and so forth. It is much slower than the second pattern.

Wanderer Joined: 09 Jun 2006 Posts: 62 Location: Florida

By the same token, however, it can still be useful to attempt to use ^ and $ whenever possible, though trying to minimize use of the * when possible. Telling the parser where the match the beginning and end of lines can be very useful in helping it discard invalid lines as fast as possible.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

Like Fang suggests, use events instead of #IFs and aliases. It's exactly what I'm doing in converting my Lusternia combat system to CMUD, and it works amazingly well.

Avoid #WAIT, when possible, though this will be improved in CMUD 2.0 with the introduction of user threads.

Data record variables and string lists will also get a huge speed boost in CMUD 2.0, so you'll have that to look forward to if you use a lot of either.

Turn off class folders with triggers you don't need, such as when you're fighting one person and only need triggers for attacks they can do, ignoring all the other player classes.

Keep your loops to a minimum, both in total count of the number of loops you execute and in the number of iterations each loop goes through. For example, some people loop on all possible afflictions (or use 80 #IF checks) looking for the highest priority one to cure, when it's faster to loop on the afflictions you actually have and pick out the highest priority from that (hopefully) much smaller sub-set list.

Arminas' suggestion of using more specific pattern matching is a very good idea, but I wouldn't recommend dropping ^ and/or $ from triggers. Using the anchors in your trigger patterns makes you less susceptible to misfiring from people talking or conjuring illusions.

Newbie Joined: 29 Jul 2007 Posts: 7

Thanks for all the help I solved the problem by switching of classes when I don't need them and by going through all my triggers. It turned out that I had gathered a lot of redundant triggerlines. And I had way to many unnecasery wildcards in them.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

You're absolutely right. I overlooked the difference between using * and a more specific wildcard in those specific instances, so I agree with you now that they are identical in functionality (but not in speed). Smile