Am 02.05.2016 um 17:00 schrieb Claes Redestad:
The reverseBytes changes were motivated by seeing slightly better
performance on the micro with the suggested changes, but after
discussing this a bit I think we should revert to the original code alone
and investigate if there's some compiler quirk lurking here separately.
Maybe (i & 0xFF00) is faster than (i & 0xFF0000), because the first can be executed by shorter
16-bit CPU op code.
Looking at HotSpot disassembler output could solve the miracle.
-Ulf
