ORC-445: [C++] Code improvements in RLEV2Util.

[fangzheng]

No description provided.

[xndai]

what if n > 64?

[fangzheng]

@xndai Hi Xiening, thanks for the catch. When computing patch width, it is possible for the input n to be larger than 64. I have added boundary check in this function and getClosestAlignedFixedBits().

[wgtmac]

Can you please provide some perf data to confirm the refactoring is effective?

[wgtmac]

make sure this won't be out of bound.

[fangzheng]

Hi Gang, I thought this over and don't feel we need to add boundary check here for two reasons:

1. in current RLEv2 encoder and decoder code, all the callers of decodeBitWidth() pass in a integer that only has the lowest 5 bits set, so the input n is always less than FixedBitSizes::SIZE (32).
2. Since this function is used to decode the 5-bit length code, it would be a programming error for a caller to pass in any value that is >= 32. In this case, returning 64 (as the original implementation does) is not helping.

[fangzheng]

@wgtmac Hi Gang, thanks for the comments. I'll add performance measurements later this week.

[fangzheng]

@wgtmac Hi Gang,
I put together a test program and some measurements here: https://github.com/fangzheng/RLEV2Util_performance

The new functions are 20 to 40% faster than the original ones.

I've also committed some new changes:

1. change the lookup arrays from uint32_t to uint8_t to reduce their sizes and get better cache behavior.
2. add a unit test TestRLEV2Util.cc to verify that the new implementation produces the same results as original one.
3. simplify the code in encodeBitWidth() to avoid calling getClosestFixedBits().

Please let me know if you have further suggestions. Thanks.

[wgtmac]

+1 LGTM. Thanks @fangzheng for the detail perf data!