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
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Thu May 04, 2006 10:29 am   

A way to speed up trigger testing
 
I was just thinking about one of my scripts and how I could make it go faster, and then I realized that the same thing I want to do would apply to trigger testing. Currently zMud slows down as more triggers. that have to be tested, are made. Even if none of them do anything script wise, and even if none of them match. My idea really doesn't help with the no match situation, but would allow small speed gains when a match is found.

The idea is to add an exclusivity flag to triggers. For simplicity of description, once a trigger with this flag is matched all triggers of equal and lower priority would not be tested. This simple view obviously doesn't quite work well with the package concept, and whether it is readily implementible to dump the matching queue for the package that already got its match I am unsure of. It would tend to rely on the underlying data structure.

I am not really sure how much of a speed gain there would be, but currently matching speed does become noticeable around 2000 triggers on my computer, without using the CTRL-Q test.

Another possible way to implement this is that once a trigger with the exclusive flag matches don't test any other trigger with the exclusive flag within that package.

With either method the idea is to allow the user to tell the matching engine that it can stop looking.

Among some of the things I would like to do with this: during my multi-line capture blocks where I know no text other then what I am looking to record will be coming in, not test any other trigger (requires priority of #COND to be able to be set seperately of its parent #TRIGGER) and frequently receieved lines such as various channels of babble are matched early and can not be used to abuse triggers.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


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

PostPosted: Thu May 04, 2006 4:39 pm   
 
Hmm, that's an interesting idea. The more I think about it, the more I like it. I think having the Exclusive flag just work within a package is probably best. Otherwise I can see someone writing a package and wondering why their trigger never fires.

But within a package, it's certainly true that *most* of the time you only have a single trigger per pattern.

Of course, I'd leave the default the way it is now so that existing stuff doesn't break. But then add this option that you can set if you want to get a bit more speed from your triggers.

Also, this only really helps when you have lots of triggers that actually match. If you get a line of text that doesn't match any triggers, then obviously it still needs to test each trigger. And since *most* lines from the MUD probably don't match any triggers, I'm not sure how much this will help the overall speed in most cases.

I guess one way you could speed things up is to start creating triggers that match the lines that you know won't match any other trigger and then make this a high priority trigger and set the exclusive option. It's sort of like those "rules" in email spam processing that say "If this matches then stop processing all other rules".
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Thu May 04, 2006 6:54 pm   
 
Quote:
Otherwise I can see someone writing a package and wondering why their trigger never fires.


Or give an extra option that lets you test a string and have cmud tell you everything it would have matched and the trigger locations if there were no exclusions. Something like

Testmatches: "You are hungry."

Has matched:
Food&Drink|Eating -> "You are (very| )hungry."
Score -> "You are hungry."

Would have matched, but excluded:
Skills|MakeSomeoneHungry -> "You are hungry."


That way people could see what's getting in the way of their scripts.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Thu May 04, 2006 7:12 pm   
 
maybe an #ECHOTRIGGER command, works like a normal echo, but also echos the triggers that would fire on it
_________________
Discord: Shalimarwildcat
Reply with quote
Zugg
MASTER


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

PostPosted: Thu May 04, 2006 9:13 pm   
 
Guinn, that's more in the line of the new trigger testing and debugging window that I am planning for later. It's a bit difference than Vijilante's suggestion, which is a quick and easy addition that would speed up trigger processing in some cases.

Also remember that zMUD already has an "Echo triggers" option that shows which triggers are firing.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4662
Location: Pensacola, FL, USA

PostPosted: Fri May 05, 2006 1:36 am   
 
yes but that is for all triggers... sometimes you dont want to go offline to test something and all the other triggers showing clutter up what your looking for
_________________
Discord: Shalimarwildcat
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Fri May 05, 2006 8:42 am   
 
How about having the "Echo triggers" option either apply globally or to single packages or to single classes? This would reduce the spam when debugging a package or class.
Reply with quote
Zugg
MASTER


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

PostPosted: Fri May 05, 2006 6:00 pm   
 
Seb, once I have the trigger debugger working, then we won't need the Echo triggers option at all. I just mentioned it to make sure people were aware of the existing zMUD feature. And before someone asks, "No", the trigger debugger is not part of the first beta version, sorry.
Reply with quote
hyliqym
Newbie


Joined: 04 Oct 2019
Posts: 1

PostPosted: Fri Oct 04, 2019 4:15 am   
 
it is my humble opinion of ONE thing (within a litany of things) that can be done to increase your trigger speed.
whichever has the lowest latency or ping rate. Readers outside the UK can search for local alternatives, or use https://speedtestfast.com/ or any service that mentions Ookla. This includes Plusnet’s https://speedtestfast.com/ookla-speed-test/ and the Ookla app for Windows 10, which also avoids the browser problem.
Reply with quote
diwajny
Newbie


Joined: 21 Feb 2020
Posts: 1

PostPosted: Mon Feb 24, 2020 9:46 am   
 
I like the idea of using direct database calls as part of the setup for a test. I've used that and it always pays off for simpler or mundane database interactions. I've also found that it can work in the opposite direction too. If you just need to check that the database has been interacted with properly it's quicker to do that as an intermediate result than to check that the ui has changed.
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