Paul Bartlett asked,
| Suppose I have a recipe something like this:
|
| :0
| * condition1
| * condition2
| * condition3
| { some nesting block }
|
| Now suppose that condition1 is the _least_ likely to be hit in this
| recipe, so that procmail would wind up going to the next recipe in
| turn. If condition1 fails, which would happen more frequently than
| condition2 or condition3, as soon as procmail evaluates condition1
| against an incoming mail and sees that condition1 fails, does it skip
| the rest of the conditions and immediately look for the next recipe?
Yes, it does. Try it with a verbose logfile and see for yourself. If an
unweighted condition fails, or if the score reaches infemum, procmail skips
any remaining conditions and goes to the next instruction at that nesting
level. [Note that if the score reaches supremum procmail does not automati-
cally consider the conditions satisfied and execute the action; any remaining
*unweighted* conditions must still pass. However, if the score has reached
supremum, any remaining *weighted* conditions are skipped.]
| If so, this could make a difference in what order I put conditions
| within a recipe and how I stack the various recipes themselves for
| the sake of processing efficiency.
Yes, absolutely.
Another factor in ideal sequencing of conditions is the difficulty of
testing them: one that examines the contents of a variable or uncondi-
tionally modifies the score is less work for procmail than one that
searches the entire head or the entire body or the entire text or than
one that forks another process to get an exit code. (Also, a weighted
regexp search where x=0 or an unweighted regexp search is less load than
one where x is not 0 or a negated search, because procmail can stop at the
first appearance instead of looking through the whole text.)
Therefore, even if they fail less frequently, you may well want to put the
lighter-load conditions first to save effort when they do fail.