Numeric changes

[camembertelectrique]

What does this PR do?

Speed up byte array to hex string conversion

Where should the reviewer start?

Method toHexString() reimplemented

Why is it needed?

Two orders of magnitude faster implementation

[conor10]

Thanks for taking the time to submit this.

Whilst I appreciate it is a speedup, is this sort of optimisation really necessary at present in Web3j given the main constraint we have is the EVM?

It would be helpful to understand what was the underlying motivation that led you to this specific change, as it sacrifices readability for performance.

[camembertelectrique]

Conor, we have an app that generates non-EVM-based raw transactions to a precompiled contract that have large payloads compared to an EVM transaction, and we use Numeric.toHexString() to encode them. During testing, we found that this call created a significant slowdown in our app. This patch resulted in a two orders of magnitude reduction in compute time, and solved the performance issue we were having.

[conor10]

why is withPrefix still here?

[camembertelectrique]

It's to preserve the functionality of toHexString and to avoid an interface change that might break existing applications.

[conor10]

but toHexCharArray is only defined in this class and could be private

[camembertelectrique]

Yes, you're right. toHexCharArray could be made private to preserve the interface as it is.

[conor10]

If you make this update I'm happy to merge.

[camembertelectrique]

I reviewed and tested the suggestion for performance improvement from @esaulpaugh but found none. I have nothing else to add to this pull, it's good to merge if you approve

[conor10]

what about the removal of withPrefix?

[esaulpaugh]

you can also eliminate one array access per byte with a size-256 encoding table:

final int[] ints = new int[] { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
final int leftNibbleMask = 0xF0;
final int rightNibbleMask = 0x0F;
for (int i = 0; i < ENCODE_TABLE.length; i++) {
    int leftChar = ints[(i & leftNibbleMask) >>> Byte.SIZE / 2];
    int rightChar = ints[i & rightNibbleMask];
    ENCODE_TABLE[i] = (leftChar << Byte.SIZE) | rightChar;
}

int hexPair = ENCODE_TABLE[input[offset] & 0xFF];
output[j] = (char) (hexPair >>> Byte.SIZE); // left
output[j+1] = (char) (hexPair & 0xFF); // right

resulting in a decent speedup https://github.com/esaulpaugh/headlong/blob/master/src/main/java/com/esaulpaugh/headlong/util/FastHex.java

And if you're optimizing for Java 9+ it's faster to encode to bytes and then use new String(byte[],int,int,int) because CompactStrings is enabled by default.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rach-id]

LGTM