Zugg Software :: View topic

Apprentice Joined: 26 Apr 2007 Posts: 113

So using #T- eatherb is more favorable over #UNTR? I always reasoned that destroying the alarm would be less heavy, in that it was removing the trigger altogether, but I do see the issue if it's having to create/destroy at that rate.

And on that line of thought, instead of calling on #ALARM eatherb -2 every other trigger, it would be more reasonable to use #T+ eatherb for the purposes of starting the timer off, right?

EDIT: Even then, I'm not so certain that is more favorable, seeing that enabling/disabling a trigger over and over can't be anymore friendlier than creating/destroying.

Posted: Tue Nov 06, 2007 6:01 am

Disabling an alarm is *much* faster than deleting it with #UNTRIG. Using #UNTRIG is doing a complete database deletion of that record, as well as deleting all of the internal cache's and then getting everything sychronized. If the Settings Editor is open, it also causes the entire Tree to be marked as invalid, causing it to be completely reloaded during the background updates.

On the other hand, using #T- simply changes one field in the record (Enabled=false), so it is *much* faster. It's possible you haven't played much with databases, but doing a simple SQL UPDATE is always *much* faster than doing both an SQL INSERT and an SQL DELETE, especially when there are a bunch of indexes to update.

Back to oldguy's issues. It's still certainly possible that there is a bug in v2.10 that is causing a slowdown. But so far I haven't seen you try to do anything to help determine where the slowdown might be. The Script Debug window in v2.11 should help in tracking down exactly what is getting executed during one of your combat sessions and how long each script takes.

But you might want to disable some of your alarms or onPrompt triggers and see if you can determine which one is causing the slowdown. You can always fight a low-level mob somewhere where you aren't going to get killed if your triggers don't work.

You shouldn't say things like "Obviously they must not be involved in combat much". That's insulting to the other posters. Every MUD is different and most people who are beta testing CMUD use very complex scripts and are involved in heavy combat just like you. Don't ever assume that just because you are having a problem that obviously everyone else must be too.

All it would take is a single script running in your combat session that isn't properly compiled to cause a slow-down. So maybe you have a bad script, or maybe there is a specific bug in a specific CMUD command that you are using.

Asilient_1: I fully understand the issues of making it easier for people to migrate from zMUD to CMUD. That's why CMUD 2.x isn't a public version yet. That's why I'm adding the Script Debugger this week to delay the public version so that we can determine exactly what is causing these problems. I was providing the information on how CMUD 2.x works so that people would better understand the issues.

Apprentice Joined: 26 Apr 2007 Posts: 113

Typically speaking, I found CMUD to be much faster over Zmud, it is just when things are coming in at a moderately high pace and it bumps my processor usage up to 100% that I get the problems (Which is basically all of the time in IRE combat.)

I'll check into the #ALARM stuff and try optimising my scripts here and there to see how much of a difference it makes.

An odd point to note, when I ran 2.10 right after install (using the same package.) I was having no speed issues, it was only after half an hour or so (probably because I had more complex scripts running.) that I noticed any slowdown at all.

Wizard Joined: 17 Jun 2006 Posts: 1201

Well I certainly don't mean to be insulting, it is just that I feel insulted every time I post because the first response is how my scripting must suck and that I must change it. Half the time I can't figure out where the problem begins so I have to post generalizations and look like an idiot anyway. Cmud is faster than Zmud, but as far as 2.0+ I think it is slower than 1.34. This may very well be because I use a whole whopping 3 or 4 alarms. However, no one seems to ever want to state a better way of doing it or explain to me what would be a better way of doing things. I just stated how I do my curing above. If a few #if and #switch statements along with a few #alarms slow it down that much then I will just stick to 1.34 I guess until I can figure out a better way to rewrite everything.

If anyone was offended I am sorry. Maybe I will just try to learn MUSH client. This is ridiculous.

Apprentice Joined: 26 Apr 2007 Posts: 113

The odd thing is, I've changed how most alarms work disabling/enabling instead of creating/destroying and I'm noticing a large decrease in processor usage even though NONE of the alarms are called upon by the test I've been using. (#20/50/100 " ") is this supposed to be the case?

Posted: Tue Nov 06, 2007 11:10 am

Tonight I managed to see something like this.. its a bit hard to replicate however.

In another thread, I mentioned that I was playing around with subbing things into my prompt. This isn't a new thing for me - I've been substituting my prompt for years now, to make it look nicer and to add a timestamp. Relatively recently though, I started using a little console app (mudbot) to display my prompt as I wish it, and negate the need to substitute it in cmud. This is important because I cannot reproduce this unless substituting the mudbot prompt.

Tonight wanted to add some extra stats to my prompt.
H:3223|2737 100|100 100% Exp:56 <csdb> <eb> <lr> < 10:52:44:828 >
I have a trigger that matches the bolded part.
I capture only the underlined part to a couple of variables.
Aside from the variable setting, there are no other commands in this trigger.
I do not bother to match the timestamp because there is no reason to.

I then created another prompt trigger:
#TR {~<lr~>} {}
I did have a #SUBS in that, but the fact is even when I removed all the commands, I experienced the horrible lag that oldguy and asilient mentioned. Disabling the trigger fixed it.

(I later achieved what I wanted with #PSUB in the original prompt trig, after I remembered that the command exists.)

I tried to duplicate this in a new session file, connecting to the mud directly, with various combinations of prompt triggers, but was not able to. This is not to say I think it is caused by mudbot - there are other explanations. But it may have something to do with prompt triggers, and if that information helps someone track it down, then this post has not been a waste of time :s

Posted: Tue Nov 06, 2007 11:30 am

Posted: Tue Nov 06, 2007 12:08 pm

A wait state actually waits until the first matching line of text after the time limit expires, which isn't a problem if you're getting spammed to buggery in combat, but might cause problems if you start using them elsewhere.

I've been trying to reproduce the extreme lag problem using the package that Oldguy sent me, but no joy so far.

Apprentice Joined: 26 Apr 2007 Posts: 113

I found a more entertaining method of testing the lag problem:

#50 touch lag

Apprentice Joined: 03 Nov 2007 Posts: 132

For my alarms I usually do something like #ALARM "TestAlarm" +1 {dosomething}. Then it runs and goes away. But there could be situations where multiple settings are calling that same #ALARM command. I had thought that if it saw there was the same alarm name going on, it would just ignore it but maybe not. Is there some better way to be doing this? It worked fine in cmud 1.34, and zmud. Well, it appeared to work fine anyway!

My alarms are all I can really see that might be causing all these lockups I'm experiencing. I don't really use onprompt triggers.

Apprentice Joined: 26 Apr 2007 Posts: 113

This is.. ODD.

The test I did yesterday (multiple times with #20 " ")

Apprentice Joined: 03 Nov 2007 Posts: 132

I went through my system today and changed all my alarms to permanent alarms, had all calling be in the form of T+, T- without creating them brand new each time and no uses of #UNTRIGGER.

The difference is amazing. The speed has increased tenfold. I can even notice the difference in how fast my settings editor will open up. Also, the confusing lockups and crashes have stopped. So basically I can actually use beta now. And I used to think I had a pretty clean system heh.

Posted: Tue Nov 06, 2007 6:59 pm

My combat system never ever makes changes to the database, except in an OnDisconnect event for things that simply must be kept between sessions (like a database of how many times I've died and what to). Things like current and max stats, affliction lists and whatnot can all be safely marked as Use Default (with nothing in the default box - in the future, I'll just use Lua variables for this, which're never automatically saved) and given a value when you start the client.

Posted: Tue Nov 06, 2007 8:46 pm

Wizard Joined: 14 Aug 2004 Posts: 1269

Novice Joined: 26 Apr 2007 Posts: 44

Why would untriggering alarms cause so much of a delay in version 2, and not 1? In the tests where you looped 20 times - was that while the alarm was active, or what?

Apprentice Joined: 26 Apr 2007 Posts: 113

That's what has me completely beat. The alarms were NOT active, the alarms were not being untriggered or called on at all. I've no idea why they would affect speed if they don't even exist. (In my test all of the alarms were untriggered.)

Posted: Wed Nov 07, 2007 8:29 am

Wizard Joined: 17 Jun 2006 Posts: 1201

I just seem to have nothing but trouble. I went and change everything. I made the alarms permanent. I added functions. I put #send on everything that wasn't an alias etc. Still there is no improvement in speed.

So I just uninstall Cmud and delete all the folders and everything form my system.

I then reinstall 2.10 completely fresh.

I open it up, close the session dialog. I open settings in the untitled session and make a new test alias. Well first I get a reading of 5 ms to send a bunch of commands. So I click the gun to disable triggers and guess what it jumps up to 20 ms. So I unclick the gun and it just stays at 20 ms after that. Why would that happen?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The 5 and 9 were with an empty window and no scrollback buffer allocated. The 20's were from it allocating memory for the the scrollback buffer. Once the scrollback buffer is fully allocated it would have dropped back down to the 5-9 range.

Apprentice Joined: 26 Apr 2007 Posts: 113

Posted: Wed Nov 07, 2007 5:43 pm

I certainly wasn't experiencing no slowdown, just nothing like the massive problems oldguy was having. With triggers disabled using the command line icon, his test alias took 15ms. With it enabled, it took about 100ms, but that's hardly surprising given the number of triggers and that's nowhere near the difference that he was reporting.

Apprentice Joined: 26 Apr 2007 Posts: 113

I think I'm ready to call quits, then. I don't see all I changed being accountable for the slowdown I posted logs of, particularly where process was taking as much as eight seconds for twenty lines before I made changes to the two seconds for the same test.

It just seems like Cmud has a little brat in it that screams "nuh uh!" on certain days. :P

Posted: Wed Nov 07, 2007 6:05 pm

As I've said, you guys should probably just wait until Friday to get the new version with the Script Debugger window. Then you'll be able to see *exactly* what is running in response to your commands and you'll get the exact timing of every line. Then you'll be able to post that log so that we can look at it and see exactly what is happening.

Also, Vijilante is correct about how the scrollback buffer works. CMUD only allocates the memory for a couple of screenfulls of text when you first start it. Then, it dynamically allocates additional memory as needed until your scrollback reaches the number of lines specified in your preferences. When it reaches this limit, it starts re-using previously allocated memory, which is much faster.

Press Ctrl-Q a few times to fill up your scrollback buffer. You'll know that the scrollback is full when the Ctrl-Q time drops.

Posted: Wed Nov 07, 2007 8:44 pm

Nevermind.