Will a variable list slow down triggers?

If I have a variable listing names (e.g. apple|banana|orange...), and a trigger that highlights these names when they appear on the mud:

Will having to match against this list, slow things down for my other triggers (e.g. attack messages), since every word is matched against the list? If so, is there a better way around this?

<triggers>
<trigger
custom_colour="15"
enabled="y"
expand_variables="y"
ignore_case="y"
match="\b(@!words)\b"
regexp="y"
repeat="y"
sequence="50"
>
</trigger>
</triggers>

<variables>
<variable name="words">apple|banana|orange</variable>
</variables>

For a start, I've read somewhere that saving functions into a script and having an alias call that function, is faster than a mushclient alias (with the function written in the box GUI). Something about compilation at the start, which makes sense. So I gather, it's optimum to use plugins and scripts when possible to maintain speed?

Took me a bit, but I finally found an old thread which dealt with this issue almost exactly. If you're just highlighting everything that matches this list, regardless of context, you're certainly going to bog down your computer, as it will be running a small script to match each and every single line. This might not be noticeable depending on the machine and what you're doing, but it can also wreak havoc with your other triggers if they have to gag a line or something. Pretty much, just make sure that your trigger will only fire when it's needed, and not for every single instance possible.

http://www.gammon.com.au/forum/bbshowpost.php?id=7898

It will be a bit inefficient, for one thing the regular expression itself has to do a lot of work, plus it has to be compiled every time from the variable. Regular expressions that don't have 'expand variables' checked are compiled once (I think).

Depending on your reason for doing it (in your case you seem to be wanting to colour the words) it can be fiddly to do it other ways.

You could run a bit of a test with the Simulate function to push through test data, and a bit of a timing test. It is probably OK on modern machines, but would in the end be slower than other methods.

The problem is, your example will match on practically every line from the MUD (they will all have words in them), so it will fire on every line.

If you narrow it down a bit (eg. "* enters the room"), then you could look up the wildcard in a table (as shown in the other thread), and then omit the matching line and redisplay it with the word coloured.