Zugg Software :: View topic

Newbie Joined: 28 Jan 2006 Posts: 4

I have just done a quick comparison of speed between ZMUD 7.21 and CMUD 1.07, and I've come up with some disquieting results. Here's what I did:

I created 1000 regex triggers, with patterns ^1, ^2, ^3, ..., ^1000 and no actions, on an otherwise blank file. I then performed the CTRL+Q speed test. ZMUD 7.21's result was around 26, whereas CMUD's was about 80. Same was true of patterns styled ^a, ^aa, ^aaa...

Similarly, the settings file I ordinarily use for my MUDding (therefore one that's closer to how a typical settings file looks than my artificial example) has scored 15 in ZMUD's CTRL+Q test, and over 45 in CMUD's one. The slowdown is also very much visible, so it's not just abstract numbers.

I haven't run further tests and the method might be flawed, but if CMUD does indeed take three times as long as ZMUD to match patterns, I for one have serious doubts regarding it's practicality - when the CTRL+Q score of a settings file exceeds 30 it's becoming increasingly unpleasant to play with.

Magician Joined: 29 Nov 2005 Posts: 482

i still have to dig into this one however let me proceed by saying a few things

1.) its beta and bugs are being worked out. So a lot of times you end up with a debug compilation rather than a "Release"
2.) with the number of changes to syntax and commands it could be as simple as readjusting your file.
i.e. i had to use %int(%1) to get my #MATH command to work or it changed my variable to a string and added to it.
3.) Keep also in mind that there are settings like the refresh of the screen and delay time before commands are sent that can also hinder those results.
4.) there are many MUD settings that can affect the overall performance as well.

Not saying your testing is inaccurate. Personally for me it appears just as fast. Course i have a really powerful machine so thats one area i dont pretend to comment about when it comes to real time performance on low-mid grade pcs.

also please remember as zugg gets problems resolved and its not processing bugs and other checks and balances it will speed up quite a bit. Optimization comes after bugs are worked out.

Just some thoughts for you.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Agreed. This is still in beta. The whole point at the moment is bugs. Speed fixes will happen extremely late in the beta and things won't be optimized until Zugg is sure they'll work.

Why have all of the speed adjustments and optimizations in when there are bugs to work on?

Newbie Joined: 28 Jan 2006 Posts: 4

Yes, I realize it's a beta, I was just curious whether this speed problem (if there indeed is a problem and it's not just a matter of my testing being skewed) is known and planned to be adressed somewhere down the line. I quite agree that fixing bugs should take priority.

Wizard Joined: 14 Oct 2000 Posts: 1368

I have written a small test trigger to help test this that should work in both zMUD and cMUD:
#alias test {
#echo Removing old test triggers...
#delclass testtriggers
#echo Creating test triggers...
#loop 1000 {#exec {#trig {test%i} {} testtriggers}}
#echo Done.
}

Posted: Mon Sep 25, 2006 4:39 am

As others have already said, we are too early in the testing process to worry much about performance. I'm well aware of the performance issues and they will be dealt with closer to the public release. Right now the current build is a "debug build" and my focus is on bug fixing and not performance tuning. As others have said, it makes no sense to performance tune code until the code works correctly in the first place.

Newbie Joined: 28 Jan 2006 Posts: 4

Right, silly of me not to have thought of it. Thanks for the reassurance and keep up the good work!