3 ms·
>always put the quickest executing condition first. isn't it put the most probably true condition first?
by jessermeyer 12y ago
>always put the quickest executing condition first.
isn't it put the most probably true condition first?
- ThePawnBreak 12y agoYou probably mean to put the probably false condition first, since if the first condition is false, the others are not tested anymore.
- jonsen 12y agoIf the first condition is the slowest you can't get faster than that. But if the first is faster it might be the only one executed.
- Someone 12y agowhen choosing between A and B and B and A You want to compare expected execution times, which are: E(A) + p(A) E(B) (E(X) =expected execution time of X, p(X) = probability that X evaluates to true) and E(B) + p(B) E(A) The first is larger if (1 - p(B)) E(A) > (1 - p(A)) E(B) End result is that it may be better to put the expensive call first, if the probability of the cheap call being true is much higher than that of the expensive call. [Feel free to extend this model by adding the time needed to make or not make the branch around the second part] In practice, if one is a function call and the other is not, put the function call last, then, if performance is inadequate, measure.
- deleted 12y ago[deleted]
- TheLoneWolfling 12y agoThis is also one of those things that an optimizing compiler with profiler (or, equivalently, a JITter) can do. (I don't know if any compilers currently actually do so.)