Performance impact of deactivating triggers?

Post Reply
reyl
Posts: 12
Joined: Wed Jul 10, 2013 5:33 pm

Performance impact of deactivating triggers?

Post by reyl »

I was just wondering if from a performance/'best practice' standpoint it would be worth deactivating triggers whenever it is known they will not be needed?

ie myAlias does a task that MIGHT need to be repeated, and thus activates myTrigger and myOtherTrigger. myTrigger waits for a line that tells us to do the thing again, and then when the mud tells us we are done with our little task, myOther trigger turns off both myTrigger and itself until next time the alias is used. Am I over thinking this?

User avatar
SlySven
Posts: 1034
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Performance impact of deactivating triggers?

Post by SlySven »

Not excessively so IMHO, unless you have a lot (where "a lot" is some unspecified but probably large quantity!) It might make things either easier OR harder to debug if some thing is not working. Some schools of software design do like to compartmentalise code into modules that can be designed and tested independently and that present a "well-designed" interface to the outside world; C++ has this potential but how well this is achieved does vary (take a look at Mudlet's source code for example!) unfortunately there some elements have "grown like Topsy" and those walls between different units do seem to be more based on the paper and wood based ones seen in some far-Eastern dwellings rather than anything made of bricks or concrete. As a 'C' coder, still getting to grips with 'C++' I may have contributed to poking some holes myself but I'm learning to carry around some 'meta-physical' filler to try and fill in some of the more obvious 'passageways' between blocks of code that interact in ways that do not use the 'doorways' that they ought to.
(This is only my personal opinion, it may be based on a lack of a full understanding of the whole picture and not meaning to undermine the effort that it takes to create and actively develop properly a Free & Open Source application that works on a wide variety of systems in a consistent way - there are other MUD clients out there but just think how many of them are actively being worked on!) *** Climbs down off of soapbox ***

Only observation I'd suggest: is that you should either include displaying something on the console when myAlias activates the triggers and myOtherTrigger deactivates them; or, if that is normally too noisy: make provision for a "debug" mode to do so when IT is switched on. This won't seem particularly useful under normal situations when everything is working fine but if you tweak something and then things start misbehaving you will be glad you had the forethought to do so... ;) :geek:

reyl
Posts: 12
Joined: Wed Jul 10, 2013 5:33 pm

Re: Performance impact of deactivating triggers?

Post by reyl »

So from the sound of things, in typical usage situations (ie mine) it's not going to be noticeable, but it's a good habit to learn? I'll try and form good habits early rather than later, hehe. One thing I do definitely do is (potentially excessive) echoes for everything, but I haven't tried making debug modes with more verbose info beyond just using echo() or display() after variable assignments to test then commenting them out when everything works.

Thanks for such a quick and informative response!

Jor'Mox
Posts: 1153
Joined: Wed Apr 03, 2013 2:19 am

Re: Performance impact of deactivating triggers?

Post by Jor'Mox »

Personally, I run several hundred triggers at any given time, mostly just to collect info from the game for use elsewhere. I haven't seen any sort of performance problems due to their presence.

User avatar
demonnic
Posts: 886
Joined: Sat Dec 05, 2009 3:19 pm

Re: Performance impact of deactivating triggers?

Post by demonnic »

As a general rule, if you're shielding your regular expressions behind substring triggers, you should be fine. The regex triggers are a lot more resource intensive than the substring triggers (I believe it goes exact match, begin of line substring, substring, then regex) so if they only get evaluated when a substring trigger for the same line goes off, it can save you a fair number of cycles.

There's an interesting forum post about it here: http://forums.mudlet.org/viewtopic.php? ... 441&p=4404

Jor'Mox
Posts: 1153
Joined: Wed Apr 03, 2013 2:19 am

Re: Performance impact of deactivating triggers?

Post by Jor'Mox »

I have found that regex triggers that are reasonably anchored to the beginning of the line can be fairly quick as well.

User avatar
demonnic
Posts: 886
Joined: Sat Dec 05, 2009 3:19 pm

Re: Performance impact of deactivating triggers?

Post by demonnic »

Well sure. As with anything regular expression related, there are better and worse ways to write a working expression. But even writing intelligent regular expressions, you're still going to get better performance off of the substring trigger types.

That being said, there are plenty of times when you don't absolutely have to squeeze all the blood out of that turnip. Folks spend too much time over-optimizing in places where they can often be more lax and just let those resources go and get some time in the breeze. There aren't that many things to do in a MUD where you'll really be taxing things that much, in my experience. Even with sloppy code and nasty regex with look aheads and the like.

Jor'Mox
Posts: 1153
Joined: Wed Apr 03, 2013 2:19 am

Re: Performance impact of deactivating triggers?

Post by Jor'Mox »

Once I made a trigger to catch every upper case word... I sort of gave up on optimizing the rest of my triggers. :-P

User avatar
SlySven
Posts: 1034
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Performance impact of deactivating triggers?

Post by SlySven »

demonnic wrote:... There aren't that many things to do in a MUD where you'll really be taxing things that much, in my experience. Even with sloppy code and nasty regex with look aheads and the like.
Well eventually I want to capture room name and FULL room descriptions and use them to identify the MUD room(s) that match within a fraction of a second, it's not the triggers that will be the bottle-neck there! :lol: This is for a MUD that prides itself on NOT using modern protocols to inform the user exactly where they are (which is a pain for the magic user who has tried to jump too far and has mis-teleported right across the world to a hostile land!) - mind you I've been caught up in messing ar..., um, revising Mudlet code for a while now and I don't see an end in sight just yet so no danger of actually seriously Mudding for some time. ;)

User avatar
demonnic
Posts: 886
Joined: Sat Dec 05, 2009 3:19 pm

Re: Performance impact of deactivating triggers?

Post by demonnic »

Perhaps I should have said instead there isn't that much your average MUD user is going to run into. And yeah, that sounds unpleasant.

Post Reply