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?
Performance impact of deactivating triggers?
- SlySven
- Posts: 1034
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Performance impact of deactivating triggers?
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...
(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...
Re: Performance impact of deactivating triggers?
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!
Thanks for such a quick and informative response!
Re: Performance impact of deactivating triggers?
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.
Re: Performance impact of deactivating triggers?
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
There's an interesting forum post about it here: http://forums.mudlet.org/viewtopic.php? ... 441&p=4404
Re: Performance impact of deactivating triggers?
I have found that regex triggers that are reasonably anchored to the beginning of the line can be fairly quick as well.
Re: Performance impact of deactivating triggers?
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.
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.
Re: Performance impact of deactivating triggers?
Once I made a trigger to catch every upper case word... I sort of gave up on optimizing the rest of my triggers.
- SlySven
- Posts: 1034
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Performance impact of deactivating triggers?
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! 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.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.
Re: Performance impact of deactivating triggers?
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.