Tim Starling wrote:
Robert Rohde wrote:
For Andrew or anyone else that knows, can we assume that the filter is smart enough that if the first part of an AND clause fails then the other parts don't run (or similarly if the first part of an OR succeeds)? If so, we can probably optimize rules by doing easy checks first before complex ones.
No, everything will be evaluated.
Note that the problem with rule 48 was that added_links triggers a complete parse of the pre-edit page text. It could be replaced by a check against the externallinks table. No amount of clever shortcut evaluation would have made it fast.
-- Tim Starling
With branch optimization, placing the check !("autoconfirmed" in USER_GROUPS) and namespace at the beginning would avoid checking the added_links at all (and thus the parse).
Another option could be to automatically optimize based on the cost of each rule.
PS: Why there isn't a link to Special:AbuseFilter/history/$id on the filter view?