Decision Speed Optimisation

Nice. This is a kind of optimization that you can't figure out by doing CPU profiling alone.

That's interesting and is something I didn't know. I don't think there would normally be parallel evaluation going on, so I do think it's the lack of branching and that bit-wise operations are just very simple/fast. I found a couple StackOverflow questions about it too, where people mostly mention branching. [1] [2]

I'm probably in the "not worth the cost to readability" camp, but I know you're a little closer to the "anything for speed" end of the spectrum. :-)

I'm actually implementing a rotated Rectangle2D.Double so that I can evaluate out-of-bounds PIF with a projected replay in Neuromancer. I was worried that it would be much slower than a standard .contains(x,y) function, so I was testing that. When I hit on the bitwise operations I thought I'd try a standard non-rotated function, and it was twice as fast as the awt.geom one. My rotated function is now slightly faster than the awt.geom as well.

I agree that sprinkling them around liberally isn't really going to make much of a difference, and will affect readability, but for something where you just have a bunch of numerical comparisons and the costs for all the branches will be more expensive than any saved time from the short-circuit provided in &&, this could be a decent speedup. The only real applications in RoboCode that would be intensive enough and have enough decisions to make this worthwhile, at least that I can think of, are in-field-bounds testing and range searches in Kd-Trees.