On their own, % and / are way slower than +, -, *, <<, >>. Cycle counts depend on your architecture, you can look them up. That mod is so slow and should be a

On their own, % and / are way slower than +, -, *, <<, >>. Cycle counts depend on your architecture, you can look them up. That mod is so slow and should be avoided is a kind of folklore based in truth - kind of like function calls being slow - but like everything time-sensitive the mistake lies in not profiling before (manual) optimization. There's an example on SO, I got similar results just now when I replicated it: https://stackoverflow.com/questions/15596318/is-it-better-to-avoid-using-the-mod-operator-when-possible https://stackoverflow.com/questions/15596318/is-it-better-to... It doesn't matter on my machine whether the divisor is 10 or 42 (as in the example), the branching is way faster. Now, maybe if the branching were not in a loop and hence not so easily predicted, it wouldn't make a difference. But if this code is not being used in a loop, optimization may be premature anyway (as indicated in my original comment). Probably f() has something to do inside the main game loop and gets called on a bunch of objects every frame. I haven't looked at the code enough to know if that's a bottleneck.