Minor speed up using MethodHandles in DataAccess #3005
Conversation
| private static final VarHandle INT = MethodHandles.byteArrayViewVarHandle(int[].class, ByteOrder.LITTLE_ENDIAN); | ||
| private static final VarHandle SHORT = MethodHandles.byteArrayViewVarHandle(short[].class, ByteOrder.LITTLE_ENDIAN); |
There was a problem hiding this comment.
| private static final VarHandle INT = MethodHandles.byteArrayViewVarHandle(int[].class, ByteOrder.LITTLE_ENDIAN); | |
| private static final VarHandle SHORT = MethodHandles.byteArrayViewVarHandle(short[].class, ByteOrder.LITTLE_ENDIAN); | |
| private static final VarHandle INT = MethodHandles.byteArrayViewVarHandle(int[].class, ByteOrder.LITTLE_ENDIAN).withInvokeExactBehavior(); | |
| private static final VarHandle SHORT = MethodHandles.byteArrayViewVarHandle(short[].class, ByteOrder.LITTLE_ENDIAN).withInvokeExactBehavior(); |
There was a problem hiding this comment.
Can you explain the benefit? I do not understand it from the provided link.
There was a problem hiding this comment.
The VarHandle has some built-in logic to handle casts. This has some overhead and tends to be a silent performance problem. The withInvokeExactBehavior() disables the casts and instead throws an error if there's a type mismatch.
e.g. without the exact behavior this would work, but with degraded performance:
short value = 5;
INT.set(segments[bufferIndex], index, value);tl;dr: it doesn't matter as long as the code is correct. But it's hard to tell that there's a cast happening behind the scenes without the option.
There was a problem hiding this comment.
Ok, I do not fully understand this but it looks like this check is only done at the creation of the VarHandle to avoid affecting performance. Have included this in this PR.
Speedup is not more than 5% for e.g. routingCH.
This lower level approach is also used in DataInput/OutputStream so it should be production ready.
Tried also with "theUnsafe" directly, but it wasn't faster.