Execution order duplication of irules and policies

if I for instance do the same redirect in a policy and in an irule

My assumption here is that you'd receive the same sorts of errors if you tried to redirect twice in an iRule, or even twice in a policy. You can almost think of the proxy as a "bucket" (please excuse the terrible analogy, but follow me here), where a request or response will fill the bucket, any evaluations and changes are applied to the contents of the bucket, and a single resulting "action" will determine what you do with it after that (empty it into the original path, dump it somewhere else, etc.). If you have more than one competing action applied to the request or response, you'll get an error. I can sort of see where you might be trying to override one action with another, and wondering which order they're triggered, or which takes precedence, but you generally shouldn't be doing that. I'd recommend, at the very least, only doing the redirects in an iRule, or only in the policy, so that there's no chance of conflict. As far as performance, I think it probably depends on a few factors. For a handful of conditions and redirect paths, the difference is likely negligible. For anything greater than a few dozen conditions, I'd recommend a data group and iRule anyway from a manageability perspective. So then the difference really boils down to the manageability of the solution (manage an iRule or manage a policy).

So in terms of cpu usage, all policies and irules are evaluated and will spend cpu cycles doing so? I know in irules you can disable events to stop the further processing of the same event(s) in other irules, but the policies have a first-match setting. My impression was that the processing of the policies will stop when that first matching condition is hit? So the question still remains if irules are processed first, and then the policies, and if that is correct am I better served with putting the most likely matching condition/policyrule at the top of the policy?