Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Jan 10, 2008 1:20 am   

[2.18] Delay caused by enabling/disabling classes during movement
 
From my other topics on the subject I had determined that there were some issues with the mapper. Along the way I discovered that enabling/disabling classes during movement also caused an additional delay. When I focused on the mapper configuration I put the enable/disable issue to the side, supposing it was part of the symptom from the mapper configuration. I recently found that I could reliably cause this delay by creating a dummy class with 10 dummy triggers that gets enabled during the course of moving. I'll supply here the details to help repeat this on your machine:

Code:
*** Setup for testing - Getting accurate walk times ***

1)  Add #var tempTime %time(sszzz) to an alias for movement, so when you type "west" this initial time gets recorded.
2)  To your prompt trigger add this to get the time it took you to make the movement:

#if (@tempTime) {
  #say Time: %eval( %time( sszzz)-@tempTime)
  #var tempTime %null
  }

*** At this point the measurements can be made ***

3)  Create a dummy class with 10 dummy triggers and an alarm that disables the class after half a second.

<class name="zTestClass" enabled="false" id="7093">
  <trigger type="Alarm" priority="70940" id="7094">
    <pattern>*0.5</pattern>
    <value>#class zTestClass 0</value>
  </trigger>
  <trigger priority="70950" id="7095">
    <pattern>RandomTrigger 1</pattern>
  </trigger>
  <trigger priority="70960" id="7096">
    <pattern>RandomTrigger 2</pattern>
  </trigger>
  <trigger priority="70970" id="7099">
    <pattern>RandomTrigger 3</pattern>
  </trigger>
  <trigger priority="70970" id="7101">
    <pattern>RandomTrigger 4</pattern>
  </trigger>
  <trigger priority="70970" id="7103">
    <pattern>RandomTrigger 5</pattern>
  </trigger>
  <trigger priority="70970" id="7105">
    <pattern>RandomTrigger 6</pattern>
  </trigger>
  <trigger priority="70970" id="7107">
    <pattern>RandomTrigger 7</pattern>
  </trigger>
  <trigger priority="70970" id="7109">
    <pattern>RandomTrigger 8</pattern>
  </trigger>
  <trigger priority="70970" id="7111">
    <pattern>RandomTrigger 9</pattern>
  </trigger>
  <trigger priority="70970" id="7113">
    <pattern>RandomTrigger 10</pattern>
  </trigger>
</class>

4)  Record your movement time as a initial snapshot to compare.

5) Add "#T+ zTestClass" to your trigger for your room name.  That way this dummy test class will be enabled after you start your movement, but before you are finished.

5)  Record your movement time as a final snapshot and compare with your earlier times.


This adds 200ms of time for me. There should be this big of an effect on runtime from the simple enable of a class with 10 triggers. Let me know if anything in the instructions wasn't clear. This seems very repeatable for me. There is an inherent delay time as the command propagates through the internet, but I'm seeing a consistent delta of 260ms vs. 60ms.

Update: I think I'm also seeing this with other mud interactions such as:
- I submit a command
- Enable a class to handle that command's text from the mud
- Disable the class after I've processed the mud text.

This may be generally applicable to all such general types of interactions with the mud, of which walking is certainly one.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Thu Jan 10, 2008 2:39 am   
 
Ten triggers really should not be making that much of a difference. On step 5, 'Add "#T+ zTestClass" to your trigger for your room name.' do you get the same effect if you put the #T+ command into an onRoomEnter event? If yes, then do you also get the same 200ms time differential if you disable your room name trigger?

Would you mind timing the #T+ command by itself? Enter at the command line
Code:

$var=%secs;#T+ zTestClass;#SHOW Time (%secs-$var)
If it doesn't come back with 200ms or so then that has elminiated one improbable possibility. Easy one to test and it is better to have it out of the way.

What was the difference on the times between steps 2 and 4?
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Thu Jan 10, 2008 5:16 am   
 
>> $var=%secs;#T+ zTestClass;#SHOW Time (%secs-$var)
It takes 2 ms to execute this on the command line from your code above.

>> What was the difference on the times between steps 2 and 4?
Nothing really. Just trying to be detailed. Step 2 tells you to put it in there. Step 4 tells you to remember the numbers it produces.

>> do you get the same effect if you put the #T+ command into an onRoomEnter event?
Yes.

>> If yes, then do you also get the same 200ms time differential if you disable your room name trigger?
What do you mean by this? Do you mean disabling the room name trigger after it has fired or just not having a room name trigger active during a move. Having the room name trigger active/inactive doesn't affect the time at all. Adding or removing the code to enable that class is what causes the extra time.

I've tried to outline all the steps as clearly as I could. It should be fairly easy for someone try to replicate these results.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Fri Jan 11, 2008 11:42 pm   
 
I ran more tests, and this affects more than movement. There is something causing extra delay when classes are enabled/disabled while receiving text from the mud.

Anytime you do this sequence it is affected:
1) Receive a start-line which you use to enable a class.
2) Use the now enabled class to trigger off a line.
3) Disable the class after #2.

Code:
Exact Instructions (This will need to be tailored to a command you run in your mud):

Baseline Measurement:
1)  Create an alias for a command you can use to get feedback from your mud, such as "msgs"

#var tempTime %secs
~msgs

2) Create a trigger to match feedback from that command, such as "Message Summary", and which executes:

#say Matched: %eval( %secs - @tempTime)

3) Run your command a few times to get a baseline of how many ms it takes for you to go from submitting your command to receiving the text back.  I measured around 35ms for me.

Altered Measurement:

4)  Create a class with ~10 dummy triggers in it.  It doesn't matter what the dummy triggers are matching.  Move the trigger created in step#2 into this class.

5)  Alter your "msgs" alias created in step #1:

#var tempTime %secs
#class zTestClass 1
~msgs

6)  Alter your trigger created step #2 to contain this:

#class zTestClass 0
#say Matched: %eval( %secs - @tempTime)

7)  Run "msgs" a few times to get the average change.  My new measurements gave me ~219 ms.

That's a 180ms change to enable/disable the class. This is a very noticeable delay for me. I use this type of technique literally everywhere in my scripts and it causes quite a slow-down.

Another strange thing I observed is that the extra delay will not occur the first time you run step #7. It always starts for me on the second execution of "msgs".
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Mon Jan 14, 2008 7:57 pm   
 
Zugg, when I originally ran into this problem you asked that I give as much detail as possible so that you could reproduce it. Is this sufficient?

As I use enabling/disabling pervasively throughout all my code, getting this resolved is near and dear to my heart. I'd have to change hundreds of implementations if this is something that never gets addressed.

I'd also suspect this would degrade performance for many others as well if they use the same sort of on the fly enabling/disabling. Perhaps they are losing performance but have yet to pinpoint this as the source of their slowdowns.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jan 15, 2008 6:39 pm   
 
Yes, that should be good enough information to help during the next round of beta testing. But since I'm in the middle of the conversion to Vista and Delphi 2007, don't expect to see any new beta versions until the end of the month or so. I'll respond to this thread again then when I actually am able to do some testing and debugging. But right now my development system is in the middle of upgrades so I can't even load CMUD into my compiler/debugger right now.
Reply with quote
ReedN
Wizard


Joined: 04 Jan 2006
Posts: 1279
Location: Portland, Oregon

PostPosted: Tue Jan 15, 2008 9:30 pm   
 
Thanks for outlining the time line. I assume you are less than eager to hop back on the bug fix grind you were on before you left for the holidays given how long you've been at it.

I'll try to bide my time. Looking back, in my case I should have delayed installing Cmud a while longer. Cmud isn't playable and I've invested so much time converting Cmud that I'm stuck making all code changes on both Zmud and Cmud simultaneously to make sure that I can still play on Zmud, but that Cmud keeps up so that it will be up-to-date when the bugs are fixed. There's no good solutions for me at this point until Cmud is cleaned up enough to be playable. I'd even consider coding around the bugs but this issue alone would entail changing over 187 separate usages of this technique. Considering this one issue alone, suddenly keeping both updated at the same time doesn't seem like such a challenge anymore.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net