Tested with the following code: http://pastebin.com/sTUuHwP2
Results are listed in paste.
Increased operation performance between 3 and 7 fold. (less drastic improvement when iteration count lowered to 1 but still within those bounds.) It also appears that while the casting method's performance remains constant, the floor method's performance increases when dealing with smaller input values but is still dwarfed by the casting method.
HUGE performance boost to locToBlock()
A more extensive test (67 million randomly generated numbers in a minecraft bias range, from -65k to 65k): http://pastebin.com/RcapRgZg
The new proposed method is consistently 16x faster, this does not change for a set of all negative or all positive numbers.
The test includes cross-checking the numbers between old method and new method for consistency.
Here is your stupid report: https://bukkit.atlassian.net/browse/BUKKIT-815
Come on @EvilSeph - pull this! It's faster and doesn't break anything - what's not to like?
On another note, I'm not getting the same 16x that I was before... But I did find a method faster than the one proposed.
I ran a few tests, this is my result:
Average floor: 103
Average cast: 12
Take note I've modified the numbers a bit to get a more stable result. It's about 900-1000% faster, if we put it that way.
I did some more research and I found this even faster: return (int) (loc < 0 ? loc - 1 : loc);
Average floor: 411
Average cast: 51
Average test: 48
I changed the numbers once again, of course. Then again, I'm not sure loc - 1 gives the correct result when it's cast afterwards.
It's not accurate (tried it).... There is still a faster and more effective way to do it, without the conditional.
@Wolvereness care to share?
Yeah, this whole discussion is mute. This fails when flooring the same number twice, or a whole number literal.