Zugg Software :: View topic

Beginner Joined: 24 Jun 2008 Posts: 16

Are there any tips or tricks to configuring CMUD properly for performance issues? My problem is such that when I add a package with any decent amount of coding behind it, whether it's just aliases and a tiny GUI or up to a full IRE curing system, my cmud ctrl-q drops by magnitudes of x4 to x6. Going through a full Mudbot curing system with about 100 triggers/aliases, my ctrl-q is still 7-10, but when that curing is in the CMUD system it is anywhere from 50 to 80. I've tried it while offline, made sure debugger was open, etc. Nothing is looping, no variable duplications, no extra capturing, nothing. It just seems purely that when I add a package with a good sized amount of coding behind it, the performance drops drastically, whether or not that code is even in use.

I do exceed what I would consider a recommended system for handling cmud, and some of the packages I am testing are not advanced by any stretch of the imagination. I have also played with setting both processor affinity and system priority (both Above Normal and High) and neither of them seem to have more than a -5 or -10 effect on the 50-70.

Thanks.

Posted: Tue Jun 24, 2008 3:41 pm

Well there are couple things that can be said. First there are couple articles around on speed improvement in general so you should search the forums.

Couple of tips...

1. Disable triggers that are not use and only enable them when needed. This can make a large difference.
2. Use local variables when ever possible (i.e. when you are not persisting data). They are are *alot* faster than regular variables.
3. Run the compatibility report to make sure all your scripts are compiled and working properly.
4. Avoid trigger off of large stringlists that are constantly updated.
5. Make you trigger text as specific as possible and avoid starting them with wild cards.

Some slightly more advance things.
5. Prioritize you triggers and consider enabling Stop Further Processing and disabling Trigger on Trigger for text that will not match anything else.
6. Consider using events for cross-package communications instead of standard variables.
7. Look at your package scoping and keep your variables references as specific as possible.
8. Try disabling all triggers then slowly, re-enabling them to see if there's a select few responsible for most of the slowdown.

These are all generic, but without being able to see your code there's not much we can tell you.

Beginner Joined: 24 Jun 2008 Posts: 16

I guess I was just curious in general, as these slowdowns are experienced just by loading the package, with no prompts firing or anything. The debugger is clean showing no scripts firing or triggers, etc. I can throw on an example package of one of the tinier ones that just includes a few buttons and no curing whatsoever, it makes the c-q go from 7 to 50 when it is loaded. I'm doing this testing all while off-line, as it only gets worse with large amounts of information pushed through it.

Posted: Tue Jun 24, 2008 4:58 pm

Even if no triggers are actually firing CMUD stills spends a lot of times checking to see what triggers are enabled and based on their priority evaluate each of them to see if them match.

Based on what you're saying you should probably focus on 1, 3, 5 and the second 5 (sorry about that.) If all else fails, try the approach in 8.

Posted: Tue Jun 24, 2008 5:11 pm

Heh. I have performance issues as well. As it currently stands:

Triggers: 377 Aliases: 245 Variables: 250 Paths: 30 Macros: 39 Class Folders: 190 Mapped Zones: 254 Menus: 19 Tabwords: 0 Status Windows: 0 Directions: 16

I guess I should apply some of Tech's suggestions - though I'm pretty sure most of my scripts don't use any extra variables. But still, my time is in the 70s. :\ My command bar locks up whenever a huge block of text shows up on my screen. *sigh*

Charneus

Posted: Tue Jun 24, 2008 5:36 pm

Ctrl+Q speed is very different to performance. Basically, the point of Ctrl+Q is to display a bunch of text that won't match any of your triggers, to establish a baseline speed for your triggers when none of them match a line.

Increasing your Ctrl+Q speed can be done in a number of ways. Disabling triggers you don't need at that moment is a good step - deleting and amalgamating triggers is another one. You can also build regexes carefully so that they fail faster - this generally means avoiding using the dot and ensuring that your triggers backtrack only when they need to. You can learn more about building better regexes on any of the sites around. You need to bear in mind, though, that increasing the speed a trigger fails at sometimes reduces the speed it matches at (that is, it rejects lines that don't match faster, but takes longer to recognise a line that does match).

Your Ctrl+Q speed has absolutely nothing to do with anything that the triggers do, because their patterns almost certainly don't match the text Ctrl+Q is spamming. The quality of your code and the speed it runs at doesn't have any bearing on your score Ctrl+Q and could be good or bad. You also should bear in mind that improving the speed of code often has other drawbacks.

Finally, are you actually experiencing any problems with this? Is the speed at which triggers match causing you any noticeable issues on your MUD? Because if you can't tell that anything's wrong, then the whole issue is pretty academic and you might as well leave it alone - it's not normally worth the hassle.

Beginner Joined: 24 Jun 2008 Posts: 16

I'm not sure how it wouldn't be indicative of issues, as when you rise above 70 (at least for me) that means your screen is starting to stutter if information is coming in faster than that. I'm getting choppy program lag and processor spikes on a machine that is somewhere around 4 months old bleeding edge. I don't have the issue in more-complex systems for ZMud and I don't remember having anywhere near this bad of chop with heavier packages around 2.18. It started around 2.25 and has progressively gotten worse. At this point I'm spiking hard enough that it becomes unplayable at times, which should be nearly impossible on my home machine.

I've checked and rechecked for loops, trimmed down some triggers and the like, but it still seems that the hit in performance is directly related to tossing in a package. One package that raises it from 7-50 has barely any triggers at all, just some GUI elements and a numpad macros. It has maybe seven triggers total in it.

Posted: Tue Jun 24, 2008 5:52 pm

This sounds like less of a "how can improve the speed of my scripts" and more of a "newer versions have made my scripts go slower" issue, in that case. It's possible that some of the changes in more recent versions have caused something somewhere to start slowing you down.

As an aside, there's a reason that you don't see the same problem in zMUD, and that's because zMUD doesn't wait for your triggers before scrolling. It scrolls text separately to the scripts that're being run, so another line could come in while a trigger from the previous line is still running. Obviously that causes problems that CMUD avoids.

Posted: Tue Jun 24, 2008 7:20 pm

You can also open the Script Debugger window to see exactly what CMUD is doing with your triggers when you use Ctrl-Q. It will show any triggers that are firing. You can also turn on the "Show compiled" message option in the debugger to see if a bunch of triggers keep getting recompiled or something like that.

It's certainly possible that something has changed to slow down your scripts, but I'd need a specific script example to test it. It's been harder for me to see problems with Ctrl-Q since just having Vista itself slows down Ctrl-Q by a huge factor compared to when I was running on XP. So I don't have a good feeling as to what a good Ctrl-Q speed is anymore during my testing. If some change in CMUD caused a speed decrease at the same time that I switched to Vista, then I probably wouldn't have noticed it.

Finally, doing a Ctrl-Q with MudBot isn't actually causing anything in MudBot to be executed. You could have a million triggers in MudBot and still get a Ctrl-Q speed of 7-10. MudBot is capturing the data from the MUD network connection before it ever gets to CMUD. And the Ctrl-Q is just displaying text in CMUD and causing CMUD triggers to fire. Ctrl-Q will never cause any of your MudBot triggers to fire. So that's not a valid test or comparison.

Just adding a package shouldn't matter to the speed at all. It's all about what triggers you are specifically added. When CMUD is testing triggers, it actually doesn't matter what package they are in...they are all stored in a global priority list by the time they are tested.