Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

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.

Posted: 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".

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Posted: 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

Posted: 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.

Posted: 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

Wizard Joined: 14 Aug 2004 Posts: 1269

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.

Posted: 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.

Newbie Joined: 04 Oct 2019 Posts: 1

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.

Newbie Joined: 21 Feb 2020 Posts: 1

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.