As I was about to do a shielded regex in the typical 'begin of line' parent, regex child manner, it occured to me - what about just making it an AND trigger with a line delta of 0, first pattern begin of line and second a regex. That'd still work as a 'shielded' one.
Has anyone tried doing any performance benchmarks on either of these ways? It would certainly be nice to know which to stick with.
Doing shielded regex differently...
Re: Doing shielded regex differently...
explain "shielded"
Re: Doing shielded regex differently...
Shielded meaning it's barred from being matched against a line unless a faster pattern - typically begin of line - matches on it. So this makes it so the light pattern is matching on most of the lines, instead of a heavy (slow) regex - when the light one matches, the regex is then given a chance to match.
The typical way to accomplish this is to make a substring trigger and drag a regex inside it, so the regex is only given a chance to match only when the parent does. I realized though that you can make an AND trigger instead with a line delta 0 with the same effect as well (in this case, AND triggers vs gates allow different flexibilities outside of this scope).
The typical way to accomplish this is to make a substring trigger and drag a regex inside it, so the regex is only given a chance to match only when the parent does. I realized though that you can make an AND trigger instead with a line delta 0 with the same effect as well (in this case, AND triggers vs gates allow different flexibilities outside of this scope).
Re: Doing shielded regex differently...
Ah, I see what you're doing. I've thought about this in the past myself, however I've never put in the work to implement it over my hundreds of triggers.
Its a good idea, though. I think in the end I would just use the shielded regex instead of a series of ands to make the proper match. For what I'm doing most of the time I want to catch dynamic content and save what I find.
Its a good idea, though. I think in the end I would just use the shielded regex instead of a series of ands to make the proper match. For what I'm doing most of the time I want to catch dynamic content and save what I find.
Re: Doing shielded regex differently...
Well... yes! I've always done it. I just realized the same shielding effect can be done with an and trigger though... wondering which one is more efficient now.
Re: Doing shielded regex differently...
how would you parse dynamic content from a line with and triggers?
Re: Doing shielded regex differently...
I don't know what do you mean, but in this case I'm only talking about shielding regexes - not other applications. Surely if something can only be done one way then it should be so.
Was just hoping someone would benchmark this
Was just hoping someone would benchmark this
Re: Doing shielded regex differently...
Thanks to ixokai for the generator script: http://mudlet.pastebin.com/L3hd7WVg
I tried 100k of either triggers, and the different was negligible - 100ms on a single input line w/ 100k triggers. I guess I'll stick with and for shielding since it'll visually make it look like a normal trigger instead of a gate which it really isn't.
Videos: http://drop.io/h4tglne
I tried 100k of either triggers, and the different was negligible - 100ms on a single input line w/ 100k triggers. I guess I'll stick with and for shielding since it'll visually make it look like a normal trigger instead of a gate which it really isn't.
Videos: http://drop.io/h4tglne
Re: Doing shielded regex differently...
Oh, and not shielding them took ~50% more time -(from 100ms to 150ms, from 200ms to 300ms) so shielding is worth it.
Re: Doing shielded regex differently...
Interesting.
When triggering a single line, how complex can a trigger get (I'm referring to multiple levels of filter chains, gates and whatever else) before it is equally efficient as using a single regex pattern? (Assume a well written pattern).
When triggering a single line, how complex can a trigger get (I'm referring to multiple levels of filter chains, gates and whatever else) before it is equally efficient as using a single regex pattern? (Assume a well written pattern).