Byte comparison boxes both bytes and converts to longs to compare (which is slow)
Description
This came up in a much more complicated example but consider a case like this:
In the compiled bytecode, both m and (aget b 0) are known to be bytes, but both are boxed using Byte.valueOf(), then cast using RT.uncheckedLongCast() and finally compared as longs:
In a tight loop manipulating and matching against byte arrays, this boxing is significant for performance.
Attached is a test that demonstrates the performance difference between the byte[] and long[] performance to get an idea of the difference.
Environment
None
Attachments
1
Activity
Show:
Alex Miller February 7, 2014 at 3:39 AM
Thanks Nicola - I must have confused it with the boolean/boolean version.
Nicola Mometto February 7, 2014 at 3:17 AM
By the way, tools.emitter.jvm uses i2l to cast the byte to a long instead of boxing && unboxing to a long
Nicola Mometto February 7, 2014 at 3:10 AM
The description states that Util.equiv() has a byte/byte comparison variant but it doesn't look like it actually exists.
This came up in a much more complicated example but consider a case like this:
In the compiled bytecode, both m and (aget b 0) are known to be bytes, but both are boxed using Byte.valueOf(), then cast using RT.uncheckedLongCast() and finally compared as longs:
In a tight loop manipulating and matching against byte arrays, this boxing is significant for performance.
Attached is a test that demonstrates the performance difference between the byte[] and long[] performance to get an idea of the difference.