This very much depends upon the CPU upon which the code is running. The 'shift' vs 'multiply' (or add to self) for doubling came about because in the past, it

This very much depends upon the CPU upon which the code is running. The 'shift' vs 'multiply' (or add to self) for doubling came about because in the past, it was very common that shifts were faster than multiplies (if your CPU even had a multiply instruction) and often faster than adds as well. Example, from the 8086 (yes, very long time ago, but this is the environment where the differences often massively mattered): https://www.oocities.org/mc_introtocomputers/Instruction_Timing.PDF https://www.oocities.org/mc_introtocomputers/Instruction_Tim... Add reg->reg: 3 clock cycles Mul: 70-133 depending on 8 vs. 16 bit size Shift: Reg with shift of 1 (which is a *2): 2 clock cycles. Now, for divide by 2 the issue is even larger (as you can't 'subtract from itself' to achieve divide by 2): Idiv: 101-184 clocks, depending on 8 vs. 16 bit size Shift: 2 clock cycles. So, on the 8086, for times 2, a shift was 33% faster than an add to self (and so much faster than a Mul that no one should use Mul for times 2). And for divide by 2, a shift was massively faster than an Idiv (2 cycles vs minimum of 101 cycles). Now, these relative values change as one moves up the x86 CPU line to newer CPU's. Intel built faster adders, faster multipliers, faster dividers, so one really has to check the specific CPU to see which instruction is faster. But the one item that will remain fairly constant is that presuming that using a shift for powers of two multiply or divide is generally close to the 'fastest' method is a good ball-park estimate that is more often right than it is wrong.