jinhyukify commented on PR #7740: URL: https://github.com/apache/hbase/pull/7740#issuecomment-3901438289
@Apache9 Thank you for reviewing this first. 😄 I first evaluated [Zero-Allocation-Hashing](https://github.com/OpenHFT/Zero-Allocation-Hashing) and [hash4j](https://github.com/dynatrace-oss/hash4j). The performance results were as follows: <img width="812" height="1000" alt="스크린샷 2026-02-14 오후 5 31 03" src="https://github.com/user-attachments/assets/2f3a2c79-23a9-416d-abc6-72c4a77c19e2"; /> There are several reasons why I decided not to adopt these libraries. ### Zero-Allocation-Hashing (ZAH) HBase provides fallback logic for `Unsafe` access and therefore does not strictly depend on `Unsafe`. However, Zero-Allocation-Hashing relies on Unsafe when reading the secret. https://github.com/OpenHFT/Zero-Allocation-Hashing/blob/ea/src/main/java/net/openhft/hashing/XXH3.java#L17 And this implementation showed slightly better performance. I believe this comes from an optimization where I pre-decode the input bytes into long values (precomputed long loads) ### Hash4j hash4j shows better performance starting from medium input lengths, but it only supports JDK 11 and above. The observed performance difference appears to come from intrinsic optimizations of functions that were introduced in Java 9 and later. https://github.com/dynatrace-oss/hash4j/blob/main/src/main/java/com/dynatrace/hash4j/internal/UnsignedMultiplyUtil.java#L36 In my personal view, hash function implementations typically do not require continuous maintenance. Therefore, maintaining our own implementation should not be considered a significant drawback. WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
