Does n >> 3 or n & 3 offer any advantage over n/8 or n % 8 respectively?

In my program memory and cpu time are constraints also this calculation will be done around 50000 times every second. Will there be a performance gain if bitwise operators are used over arithmetic ?

It is highly unlikely that it would make any difference; CPUs wouldn't care about this sort of thing for decades.

In general, if you're worried about performance before you have any actual indication that the performance is below your needs – you're going to have a bad time. Modern hardware, and the JVM's optimising code is so incredibly complicated, even the JVM performance engineers themselves are on record that they have a very hard time just looking at code and then guessing if it can be made faster with cheap tricks like trying to replace a division by a bitshift.

The solution is to simply never engage in that sort of thing: If you have performance needs, write them down, and use profilers to figure out where to look (because generally 99% of the CPU resources are spent on 1% or less of the code – so before starting performance measurements, you need to know what to measure).

Once you know, use JMH to actually test performance. That's what it is for.

IF JMH tells you that the bitshift is faster (I highly doubt it), know that this result does not necessarily translate to other CPU architecture.

My observations of doing some simple testing would indicate yes, it makes a difference. No I didn't use JMH so I know I'll get some push back. But regardless of the order of testing the bitwise operations were always observed to be faster. I can't say if faster equates to advantage but until proven otherwise I will continue to favor them when possible.

• (i&1) == 1 is faster than i%2 == 1
• i>>3 is faster than i/8

And I have seen this in the API code before, documented as being faster but I haven't tried it.

• a<<6 + a<<5 + a<<2 vs a*100

And then there is this for the bit shifting.

Arithemetic Benchmark