Plugins and Performance

Posted by Candido on Wed 18 May 2011 05:09 AM — 3 posts, 14,993 views.

USA #0
I have a theoretical, optimization sort of question. Is having triggers in your world more efficient than having them in plugins? My instinct is yes because of the implied 'keep evaluating' between the world's and the plugin's triggers: if a world trigger matches on a line, the plugin will still evaluate that line, whereas if all the triggers were in the world, processing on that line would stop once one trigger matched. This is how it appears on the surface, but I wanted to check just in case there was some multithreading or something behind the scenes that actually made it more efficient to use plugins.

If you're curious, the reason for this question is because I want to separate large amounts of my triggers into plugin modules, which people will pick and choose from according to need. Plugins obviously are the cleaner choice for this, but if they are less efficient computing-wise, I can essentially accomplish the same thing with an EnableTrigger/EnableGroup approach instead. This would also give me the advantage of being able to edit the modules with the Mush GUI instead of the painstaking process of editing plugin xml.
Australia Forum Administrator #1
Well I suppose you get more evaluating if you split them between plugins, but how big a problem is that really?

A quick test shows that my triggers are taking about 2 microseconds to (attempt to) match. So that's a lot of trigger matches you can do in a second (like, 500,000).

And this efficiency gain that you propose would only occur if you regularly get an early one matching and blocking the others. For "ordinary" lines (like room descriptions) there wouldn't be much in it.

Personally I like plugins because they keep things organized. Plus you can just share them between world files, without having to wonder if one of your hundreds of triggers was only relevant if you are playing a caster or a warrior.

And you can always make new triggers in the GUI interface, and then use the Copy button to get the correct XML to just paste into the trigger file.
USA #2
Thought about what you said and looked into it further. I just assumed 2900 triggers was what was pushing it, but it turns out I was focusing on the wrong thing, ha.

GetInfo(233) = 189 seconds (total time spent matching triggers)

GetScriptTime() = 1290 seconds...

Thanks for the advice. Have a lot of script optimizing to do now.