CMUD speed issues.

by Isuka

Back to Mechanic's Corner.

Catarin2009-03-11 13:18:01
QUOTE (Isuka @ Mar 10 2009, 10:15 PM) <{POST_SNAPBACK}>
Not to perpetuate the necro, but I think it's fair to say I was running cmud on a quad core (3 ghz) with 4 gigs of 1066 ram. It wasn't the computer slowing cmud down... i think it had more to do with my usage of events.


I wonder how heavy one has to use events for this to actually be noticeable. My system raises a fair number of events so other people can hook their own scripts in but only uses a handful in the system itself to do anything and that was mainly just to see how the mechanic worked than because of any actual need to use events internally. Though he events I do use are called pretty constantly in the heat of battle and no speed issues arise.

Cmud is an interesting case really. Two people can run the exact same system and one have speed issues while the other doesn't. Though usually in that case it's a matter of computer specs. I suppose I'm fortunate in never having the issue persistantly. There are a hundred different ways to do the same thing in zscript so if one way seems to be causing problems it's not too hard to just do it a different way if you're familiar enough with it. But anyway, it is possible (and not even that difficult that I've noticed) to make a robust system in cmud that doesn't lag anytime you get into a heavy fight. But I wouldn't complain if he got rid of threading!
Unknown2009-03-11 14:50:54
I used events a lot in my CMUD system, and I'm sure that's what killed my speed. I was firing several OnPrompt events, for example, and also had events for adding/removing afflictions/defenses, etc.

The great thing about MUSHclient is that you could write some of the least efficient script code in the world, and it would still run faster than zMUD or CMUD. There's really not such a need for optimization and workarounds, which makes the coding a bit more fun for me.
Catarin2009-03-11 15:34:24
QUOTE (Zarquan @ Mar 11 2009, 08:50 AM) <{POST_SNAPBACK}>
I used events a lot in my CMUD system, and I'm sure that's what killed my speed. I was firing several OnPrompt events, for example, and also had events for adding/removing afflictions/defenses, etc.

The great thing about MUSHclient is that you could write some of the least efficient script code in the world, and it would still run faster than zMUD or CMUD. There's really not such a need for optimization and workarounds, which makes the coding a bit more fun for me.


From what I've seen with others, I've always thought that the real speed problem might actually be more to do with heavy usage of the prompt as the driver for the system i.e. lots of things happening every time the prompt fires. If I remember from looking at one system that was having problems, it had no onprompt events at all but relied heavily on the prompt and had the same speed issues. This could also explain why I've never encountered serious trouble as I've never done a system that relied on the prompt for the bulk of system processing.

The only events I actually have in my system are adding/removing afflictions and tracking of cure balances. Along the way I tested using events, using aliases, and using functions all for the same task and the speed differences are not noticeable.

But at the same time I'm probably offbase since I'd guess you did testing with your system bypassing the events and the problems were alleviated. Though I am kind of curious why you decided to use events so heavily? From my understanding they are really more there so that other packages can get information from the main package and integrate better into it. Making an alias or function is just as easy for intrapackage communication. Though I guess if you had several different packages all interacting with each other, it would make sense.
Unknown2009-03-11 15:50:26
If I can't use the prompt trigger as the driver for my system, then I don't want to use the client, period. And, I didn't give expression triggers a second thought in CMUD because they were garbage in zMUD and I just didn't trust them. smile.gif

I decided to use events as an easy way to hook not only other packages into my system, but as a way for me to modularize things internally without having to use multiple triggers on the same pattern, just toggling events with various priorities.
Isuka2009-03-11 15:53:44
QUOTE (Catarin @ Mar 11 2009, 08:34 AM) <{POST_SNAPBACK}>
From what I've seen with others, I've always thought that the real speed problem might actually be more to do with heavy usage of the prompt as the driver for the system i.e. lots of things happening every time the prompt fires. If I remember from looking at one system that was having problems, it had no onprompt events at all but relied heavily on the prompt and had the same speed issues. This could also explain why I've never encountered serious trouble as I've never done a system that relied on the prompt for the bulk of system processing.

The only events I actually have in my system are adding/removing afflictions and tracking of cure balances. Along the way I tested using events, using aliases, and using functions all for the same task and the speed differences are not noticeable.

But at the same time I'm probably offbase since I'd guess you did testing with your system bypassing the events and the problems were alleviated. Though I am kind of curious why you decided to use events so heavily? From my understanding they are really more there so that other packages can get information from the main package and integrate better into it. Making an alias or function is just as easy for intrapackage communication. Though I guess if you had several different packages all interacting with each other, it would make sense.

I, for one, used events rather than either multiple triggers for the same line or multiple actions within the same trigger. Very little was run on my system off of the prompt. I got vitals from the ATCP line, and all of my curing stuff was triggered on affliction, on affliction cure, or on balance regain. Of these three, only the balance regain was an event.

I do basically the same thing in MUSH, though rather than an event it's an alias I'm calling. Though, I'm glad I had the problems with CMUD, in the end. Otherwise I never would have tried MUSH, and there are so many things other than speed that I've come to love about MUSH.
Catarin2009-03-11 16:05:09
It would be nice if Zugg could figure out what the problem is. Though that would first require an acknowledgement of the problem I suppose and he seems to have some blinders on about some of the more persistant problems IRE users have. Cmud is a very nice client - when it works. I suppose he'll start noticing when he loses more and more sales as people find other clients that do what they need without the hassle.
Desitrus2009-03-17 15:31:04
Lardwolf, lawl.
Unknown2009-03-17 16:02:42
Eh, there is a new version now out in beta it seems (I keep getting the prompt to download it), so perhaps things will get a bit better with CMUD soon.

I really like being able to just quickly code my own stuff, as well as use a decent system (props to Catarin for making one), so MUSH just isn't palatable, no matter how great Treant is. I'm an old woman and don't want to spend weeks learning a new scripting language!
Desitrus2009-03-17 16:28:38
QUOTE (Sadhyra @ Mar 17 2009, 11:02 AM) <{POST_SNAPBACK}>
Eh, there is a new version now out in beta it seems (I keep getting the prompt to download it), so perhaps things will get a bit better with CMUD soon.

I really like being able to just quickly code my own stuff, as well as use a decent system (props to Catarin for making one), so MUSH just isn't palatable, no matter how great Treant is. I'm an old woman and don't want to spend weeks learning a new scripting language!


I wouldn't do that until Cat ok's it, Zugg's betas notoriously break systems.
Unknown2009-03-17 17:34:03
Oh, I know better than to use Zugg's beta. Just saying, another new version (even if in beta) implies that he is continually updating and improving things.
Narsrim2009-03-17 17:36:46
Just reading through the thread, I'm curious as to what people are talking about.

I use Cmud with Catarin's system, and I have no speed issues whatsoever.
Isuka2009-03-17 17:39:10
QUOTE (Narsrim @ Mar 17 2009, 10:36 AM) <{POST_SNAPBACK}>
Just reading through the thread, I'm curious as to what people are talking about.

I use Cmud with Catarin's system, and I have no speed issues whatsoever.

I think the speed issues have to do with usage of the event system, gathering from comments I've seen from others, and from my own experience.
Vhaas2009-03-17 18:19:54
I use CMUD with Catarin's system currently. Every time there is a raid/revolt on the other side of the world, a hamster hunt, or even just a busy hour I get lag. If I log off and jump onto MUSH though, everything is black lightning again.

I also find that about 40% of the time I open up the settings folder to create, edit, or delete something, it glitches and fails to add/remove the item, or folders refuse to open and every click takes me back to the outside of the main folder...

Desitrus2009-03-17 18:29:46
I had lag before I got a supercomputer.
Unknown2009-03-17 19:02:12
Yeah, lag or no lag, Zugg made me abandon hope that he was ever going to fix all the issues I was having with CMUD with every new release. He is always working to improve his products, but he introduces almost as many problems as he fixes. I paid for my CMUD and then fought with it for more than a year, hoping he'd make it work, before I finally couldn't take it any more.

Nick is always improving his product, too, and he doesn't even charge for it any more!
Unknown2009-03-17 19:44:20
I'm sure eventually I'll move to MUSH (or maybe mudlet?). Right now, my MUD progression has been:

Avalon: completely manual
Aetolia: mostly manual (dead little lovechild of two systems crashing + me being too lazy/ADD to fix that)
Lusternia: tentatively trying out a system

I suspect, in time, I'll shift closer and find time (perhaps on my 3 month break from work) to develop a more technical and adroit combat setup. However, for someone who finds a system itself disconcerting, being able to maintain some control over things (ie, knowing the codebase) is important.

CMUD is not my ideal - it has issues. It's awkward at places and hates temp triggers/variables. I'll attest to the lagging, but IREs have always had that laggy feel, even when operating without settings. I think it's something to do with how the lines scroll. So...not too overly hung up on that aspect of things. Yet.
Gregori2009-03-17 19:55:42
I totally love cmud. I use it all the time... as a Lusternia help file editor and news post writer. It works awesome for that. No speed issues at all. /sarcasm (though I am serious about the only thing I will ever use it for after having paid for it and being sorely dissappointed)
Unknown2009-04-05 06:47:02
CMUD is awesome in my opinion, I dont have much speed problems with it and the coding is much more easier and less complicated then ZMUD, well as much as I had coded in ZMUD. ZMUD makes you type more over and over again and so because of the many checks for each effing trigger line, speed was an issue when I had a half system in ZMUD a long time ago. biggrin.gif

But CMUD now is much smoother and faster for me. Plus with all the EVENT and stuff, it'll just take some time for me before I can understand the whole Zscript completely.

Apparently, I cant learn Lua. I read it, but nothing goes in. Like I'm immune to learning Lua or something. Lol. Yes, MUSH is super fast, but I cant get the hang of the language at all.
Unknown2009-04-05 12:05:55
CMUD is fast enough until you do the wrong things with your scripting and/or packages, apparently. You wouldn't notice anything's getting slow until it's too late to turn around and redo everything. Heh.

Did you know CMUD also has Lua scripting built into it? If you do want to learn it (and I highly recommend it), you should consider looking at the Programming in Lua text online and the Lua Users' Wiki, especially the section with sample code snippets.