mouss put forth on 3/8/2011 5:03 PM: > [WARNING: Steven CC'd] > > things. so I'd say, do not consider performances as a primary target. go > for catching spammers first. only tune after you get the irght rules, > and only if needed (I personally don't tune anything here. I'm happy to > focus on catching spammers).
Likewise. In my particular case execution time of the table is irrelevant. However, the execution latency of very large tables on busy systems piqued my curiosity, giving me a desire to learn more, so I can avoid adopting potentially bad habits now that may come back to haunt me, performance wise, in the future. Also, it's very possible, maybe more likely than not, that I misunderstood some of Steven's advice, or took it out of context. (Steven, sorry for inadvertently dragging you into the mosh pit) :) Some who have been working with regular expressions for a long time may feel otherwise, but at this point I find them fascinating. From a spam fighting standpoint they can be extremely powerful. Again, I just want to make sure I develop good habits now. WRT Viktor's earlier post, I have seen examples of the grouping with if/then blocks. In fact, the fqrdns.pcre file makes use of them. Although I'm not sure it's well optimized in this case. There seem to be an enormous number of expressions within a single if/then block, and IIRC, there are only three such groupings in the set of 1600+ expressions. So there's probably room for more performance optimization. At the table's current size though, I'm guessing the potential performance gain wouldn't be worth the tweaking labor. -- Stan
