Zugg Software :: View topic

Wizard Joined: 17 Jun 2006 Posts: 1201

What in the world. You know I thought Cmud was supposed to be all about making things faster and better. But good lord I try and test this version and it's nothing but slow.

For example, in Cmud 1.34 I have an alias to inrift all of my herbs.

inriftall:

inr all plant1
inr all plant2
inr all plant3

....all the way to like plant 15 or whatever.

Well in 1.34 and even Zmud all those commands are sent in one swift sequence, but in 2.10 it's like forever just to send 15 commands! There is like a delay between each line and when it prints to the screen it looks like it's moving through mud trying to get to the MUD.

So I get on the MUD and try to do some things, get in some combat, get all afflicted, and I can't even move or type anything on the command line because it's so damn slow it is waiting to complete all of the curing sequences going on. I mean 1.34 it works fine but I just can't understand why there is such a big difference here. Like I said just sending multiple commands in a row like that is ridiculously slow. I was thinking maybe it was my OnPrompt event firing on every prompt but then I ran a couple of aliases like the one above and it is just slow period! If it is taking that long to go from one line to the next I guess I will just stick with 1.34 or just go back to Zmud and not worry about this multi-threading.

Also on Control+Q it took around 50 in 1.34 and in 2.10 it takes over 60 for the same exact package. What is the difference there?

I don't want to build a robot to go to MARS. I just want a client that will execute with speed and efficiency without error. Yes I know this is beta. :-) Again maybe someone can help me out here.

Wizard Joined: 17 Jun 2006 Posts: 1201

Okay let me also add that it is only like this when I am connected and online. I can't figure out why. If I run that same alias I described above it's like normal and sends all the commands immediately so I am at a loss.

Here is the difference in the amount of time it took just to go through these commands. I simply added a local variable to store %secs before the first line and then after the last line I subtracted that from %secs.

Offline time...

inr all ash
inr all bayberry
inr all bellwort
inr all bloodroot
inr all cohosh
inr all ginseng
inr all goldenseal
inr all hawthorn
inr all kelp
inr all kola
inr all lobelia
inr all echinacea
inr all moss
inr all pear
inr all sileris
inr all skullcap
inr all elm
inr all valerian
inr all myrrh

76 ms

Online time...

inr all ash
inr all bayberry
inr all bellwort
inr all bloodroot
inr all cohosh
inr all ginseng
inr all goldenseal
inr all hawthorn
inr all kelp
inr all kola
inr all lobelia
inr all echinacea
inr all moss
inr all pear
inr all sileris
inr all skullcap
inr all elm
inr all valerian
inr all myrrh

686 ms

Enchanter Joined: 09 Sep 2007 Posts: 605

Yeah.. I've check Ctrl+Q while offline right after installation of 2.10

2.09: 1.8-1.9
2.10: 9.1-9.8

5 times slower

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am also seeing a significant slowdown with 2.10. My tests of CTRL-Q showed it taking 2 times as long as 2.09. That ratio was reasonably constant between allocating memory and straight scrolling.

I did my tests on the first launch after a clean install, and a number of subseqent launches without testing anything else.

Wizard Joined: 14 Aug 2004 Posts: 1269

I'm seeing 2.10 two times slower, like Vigilante, than 2.09 with Ctrl-Q on the untitled session. I didn't notice any difference when connecting though, and aliases that send commands to the mud work very fast for me. Do you have stuff that gets enabled when you connect and disabled when you disconnect?

Enchanter Joined: 09 Sep 2007 Posts: 605

7 hours after my previous post.
2.10: 3.3-3.8 Confused

Posted: Sat Nov 03, 2007 5:18 pm

Did everyone do a fresh install, or install over the previous version? I'm not seeing any slowdown on my computer at all, so I'm not sure what's causing it. My Ctrl-Q speed in 2.10 is the same as in 2.09. This is in CMUDPro...maybe there is a difference between CMUDPro and regular CMUD?

Enchanter Joined: 09 Sep 2007 Posts: 605

I made uninstall first, after that install CMUD in the same directory

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am using the regular version. Having seen this mentioned I did a CTRL-Q test with 2.09 and noted the times. Next I renamed the 1 folder of packages that I have been working with. I did an uninstall of 2.09 and then deleted everything else. 2.10 was installed to the same directory, which contained only the 1 directory of backed up files. My next step was to backup the default.pkg in case of troubles, and so I can verify timestamps. The first launch done by the installer included all the inital update steps, and import of sessions from zMud in the CMud sessions.db. I then pressed ESC at the sessions window I began a CTRL-Q test. I retested it enough times using launch , ESC, CTRL-Q to say that there is a general slowdown.

Posted: Sat Nov 03, 2007 5:37 pm

Hmm, nevermind, now I see the problem too. Maybe some sort of debugging is still enabled. I didn't see the slowdown when running my development version from Delphi, but when I downloaded and installed the released version, then I see the slowdown. I have no idea what changed to cause this, but at least I can reproduce it now.

Posted: Sat Nov 03, 2007 5:44 pm

Oh, doh!

OK, the problem with the Ctrl-Q test is that when I was doing the thread testing, I changed how the Ctrl-Q test works. In previous versions, it sent the entire Ctrl-Q buffer to the screen at once. In 2.10 it sends it line by line. That's why Ctrl-Q is slower in 2.10.

This doesn't explain the slowdown's originally reported by oldguy2, so I don't know what is wrong with his scripts. My guess is that he has some kind of other triggers or scripts that are running and slowing things down.

In any case, please do your speed testing in CMUD 2.10 using the %secs function and *not* with Ctrl-Q. I'll restore the previous Ctrl-Q procedure in the next update so that we can compare apples to apples.

So, please continue testing 2.10. It is *not* corrupted as far as I can tell. Sorry the Ctrl-Q thing was a red herring and caused all of this confusion.

Wizard Joined: 17 Jun 2006 Posts: 1201

Nothing else was running. Thats the time it took for CMUD to get from the first line to the last line of the commands in that alias. All I did was execute the alias offline, and then I logged in and did it online. I did use %secs as I stated and as you can see even if another script was running that is a ridiculous amount of time.

See I don't understand how it can be something I am doing. It's ONE alias! There is not even any complicated scripts in it. All it does is send about 20 lines of text in a row to the screen. I logged in hit that alias and recorded the time it took and logged out.

Again, if there is this much of a change between 1.34 and 2.0+ multi-threaded versions then CMUD just got worse not better. How can it jump from around 76 ms to over 686 ms just to send around 20 lines of text? The ONLY thing that would have been running is my OnPrompt event. I will disable that and try it again, but still I have the same OnPrompt event firing in 1.34 on every prompt and it didn't bother the speed at all. So what is the difference and why am I going from 76 to 686?

Posted: Sat Nov 03, 2007 6:50 pm

When someone reports a bug that nobody else has seen (and since all the reports but yours refer to Ctrl+Q, that seems like a fair assumption), it's normally a safe bet that it's something that one person has done. That doesn't mean that it always is, but it's best to work from highest probability to lowest when suggesting causes of a problem.

So, with that said, by "nothing running" do you mean that your package was completely empty apart from this one alias, that you had disabled all other aliases and triggers, that you had disabled triggers using the gun icon on the command line, or what?

As an addendum, to your edited post (I wrote this post before you edited it, but forgot to click submit):

Wizard Joined: 17 Jun 2006 Posts: 1201

Zugg has the same exact package I am talking about from where I sent it the last time I posted here. I showed you the times above. I explained the problem. Why would a few scripts running cause that much of a delay? It's just like if you entered 20 short lines of text in the command line and hit enter. I don't care if I had 10 scripts running, it should not take almost 700ms to complete that task of sending those 20 short lines. I do not have this problem with 1.34 at all. ALL of my scripts execute this much SLOWER.

Another example is that I have a little script to sort all of my vials. It will loop through two different stringlists and send to put those vials into a pack in order and then it loops through those lists again and takes them out of the pack in order. In 1.34 it executes so fast I can barely see it going by on the screen because this is around 100 or so vials. In 2.10 it is like I am writing line by line out by hand onto the screen...

So again what would cause this problem? Is a thread getting stuck? What is it? I would appreciate some sort of answer rather than a pointing finger. By the way, I first mentioned the Ctrl+Q so yes mine did mention it. I'm just sorry that is what everyone jumped on. I know some of you must have an OnPrompt even firing that contains other aliases and things. No one else has this problem at all??????

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Oldguy2, your original post mentions CTRL-Q, that is why a number of us tested that. It is a standard test that we all can do without your packages in front of us, and without connecting to a specific mud. Once Zugg found what was going on there we can move on to doing tests similar to the other you described.

For this particular test I used the untitled session. I created an alias with your list of commands and 2 other lines, making the contents of the alias

Posted: Sat Nov 03, 2007 7:48 pm

I tried this both offline and on before my first post and got 30ms both times. I tried again just now just to make sure, and it's still the same.

Try creating a new session that connects to the same MUD and try running this alias with a fresh package loaded, offline and on. That'll help us determine if it's specific to your package - if you give the name, Zugg will be able to take a look with that package loaded and see if it's the culprit, too.

I'm sorry if you took my post to be some kind of insult - far from it, if anything I should be thanking you for taking the time to test and report bugs, and I am: thankyou for taking the time to report this very serious problem. Fact of the matter is that, given that nobody else has seen your problem, it's very likely that there's something specific about your setup that makes you suseptible to this problem and nobody else. Whether it's a setting that's not compiling because of a bug, something that was corrupted by an earlier beta version that this version is more sensitive to, or whatever, it's very likely to be something on your system that causes the problem. That's why I'm asking you to provide more information about how to cause the error.

You ask "what would cause this problem?" - the answer is we don't know. If we did, it wouldn't be a bug, it'd be an ex-bug. The whole idea of doing more testing is to find out the cause so that the bug can be reproduced and fixed.

Enchanter Joined: 09 Sep 2007 Posts: 605

First Vijilante script runs offline at 11ms and I did not notice any changes with additional command input trigger - the same 11ms

Wizard Joined: 17 Jun 2006 Posts: 1201

Okay...I am running Windows XP Professional with an AMD Athlon 64 3800+ CPU and 1 GB of RAM.

I got online a second ago and went through each class folder one by one disabling them and then ran the aforementioned alias each time. Each time the time dropped significantly around 50 ms or so. However, even after disabling ALL of the class folders, meaning EVERYTHING, and just having this TEST alias as the only thing not disabled, it still came up with a time of 200 ms to enter those few commands. This means I had absolutely NOTHING running. However, when I disable the all triggers by clicking the little gun that drops down to around 40 ms. Offline the time is 26 ms with everything disabled.

Therefore, I can't see how it is anything that I have done. It's just flat out slow as hell while connected. Also since none of those triggers are ONINPUT, why does disabling them decrease the time? Sorry but I am not a GURU here. Why would it loop through everything or whatever it is doing to add all of this time in just sending a few commands through an alias that has nothing to do with text being received but instead being transmitted.

Edit: Oh yeah and let me add to this. The same thing happens OFFLINE as well. When I said the time offline was 26 ms I meant that was with triggers disabled by clicking the little gun. When I unclick it and enable triggers the time shoots up 11ms to 37 ms. That's crazy. It shouldn't take but 2 ms to send 15 lines of small text.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

To explain the difference between the gun icon and just having everything disabled, you need meerly count your total number of triggers. For some reason which I will get to, they all are getting looked at for the enabled state with each of those commands.

I am going to assume that your package can trace its origin to a .mud file. zMud used to have some weird preference options that are not accessible through the GUI in CMud. One of those was the Trigger on Commands, I am going to guess you had it on in zMud. This is of course no longer necessary with Command Input triggers. Enter at the command line

Wizard Joined: 17 Jun 2006 Posts: 1201

Same test in version 1.34. Everything is disabled but this one test alias.

Offline

31 ms

0 ms when triggers are disabled by clicking the gun

Online

31 ms

15 ms when triggers are disabled by clicking the gun

Oh and you assumed wrong. I created this package from scratch in 1.34. Also "inr" is not an alias. The line of text "inr all bloodroot" is just that...a line of text. The alias that I put all of these lines of text in is called TEST for this purpose.

Basically I could send 15 or 20 other lines of random text as well. I could send 20 lines of "This is a test" with the alias as well. It's a single alias that is sending 15 or 20 lines of text to the MUD. I really don't understand what you are talking about with this multiple aliases.

This is the same EXACT package by the way. So the question is, what has changed between 1.34 to 2.10 to make it this slow?

Also just to make sure you believe me. I entered your #SHOW %pref(TriggerCom,0) into the command line and the result was 0.

Edit: By the way, I just tested with your #send suggestion and in 1.34 both with and without the triggers being disabled by clicking the gun the time is 0 ms which is awesome. I just cannot understand what the problem is with 2.10 version and why it is so horribly slow both offline and super slow online. It's not my package. I also enabled all the class folders in 1.34 and did the same test and again the results are 0 ms and 0 ms...that is with everything in the package enabled meaning all triggers, aliases, variables, classes, and so on.

Wizard Joined: 17 Jun 2006 Posts: 1201

Wizard Joined: 14 Aug 2004 Posts: 1269

oldguy2, how fast is using #SEND in 2.10?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Since we can't replicate, even with are own very large packages of settings, and just in case it never quite connected for you before both Fang and I play on Achaea as well; we have to rely on you to make all the test. Doing the offline and untitled session test just establishes a baseline. A comparative test with 1.34 doesn't help to make a baseline.

Since you were kind enough to post your system specs, and did a similar baseline test we can move on. Eliminating possiblities from the cause of a problem helps. It may sound crazy, but even trying and eliminating ludicrous possibilties is helpful.

Towards that end:
Did you check #THREAD, as requested, to assure that no other script got hung?

Do you have alarms that might be active at any point in any of these tests, or before you have a chance to execute the alias online?

You mentioned trying #SEND with 1.34, did you try it with 2.10? What effect did it have?

Did you try filling the scrollback buffer prior to going online to make sure it is not a scrolling issue?

Did you turn off triggers prior to login, login manually with #CH and #PW, then test your alias to make sure no other script ever ran?

Did you try copying your package file, launching up the session, deleting all other settings in your package, then running the test alias? You can delete the one and rename the copy when your done, just make sure to get the filename right.

Does it take just as long if you execute the contents of the alias from the command line?

Does it take just as long if done from a macro instead of an alias?

How about an #ALARM, did you put the code into an expiring alarm to test it?

Final question...will you please try everything I just asked about and report back? Those are the kinds of tests I would be doing if I had this problem with my settings. I might not do them in that order; but I can't say which, if any, should be skipped without knowing the results of some of them.

Wizard Joined: 14 Aug 2004 Posts: 1269

Wizard Joined: 17 Jun 2006 Posts: 1201

Well I can answer you Seb right now that none of the above are true. I have no aliases that match those words and none of it matches an oninput trigger. I also disabled all class folders containing everything before going online.

I will reinstall 2.10 and check again, if I can keep people from trying to kill me 5 seconds after I log in. I guess I can go create a whole new character.