I don't have the willpower to hand write 900 triggers in the GUI, so I want an approach that lets me add messages and handle them one at a time to a file or table in a script then handle it from there. As a quick test I ran a sample pattern through both the built in string.match() and through a compiled regex through the rex table that gives you access to the PCRE bit of Lrexlib. On this abysmal computer, 86400 of the sample PCRE match was 0.439s, 86400 of the Lua Patterns match was 0.12s.
0.12s at worst case scenario would be close to acceptable, but I am hesitant to use Lua's Match as I want to use named captures with these so I don't have to do any complicated code(or spend a lot of time) sorting each trigger by what variables they capture and which order they'll be in(might have user first then target, might be the other way around), and as far as I know, there is no way to return named captures from a string.match() call.
I know I can build the system the way I want by matching regex on every single line, but it looks like that will likely be too slow. I know I do not want to write out a trigger for each message in the GUI. I've considered generating tempRegexTriggers on startup for each message, but I don't know what kind of a real speed gain I'll get from letting Mudlet handle the triggers instead of triggering every line with a lua function of "return true".
Questions:
If using lua patterns would be quicker in the long run, is there a method of returning named captures that I'm unaware of?
Would tempTriggers have a significantly increased speed over parsing every line manually with pre-built regexes?
Edit: For reference, these are the example tests I'm using. They're pretty indicative of kind of messages I'm parsing: