gianm commented on issue #9308: Add MemoryOpenHashTable, a table similar to ByteBufferHashTable. URL: https://github.com/apache/druid/pull/9308#issuecomment-582136796 > @gianm wondering where the perf increase is coming from ? is it the overhead of BB bound checks ? or other factors ? wondering if it make sense to wait for https://openjdk.java.net/jeps/370 that IMO has a cleaner API and will be part of the JDK thus no low level unsafe stuff. Some of the increase is because a couple of important Memory APIs are implemented more efficiently than the corresponding BB API. For example, `Memory.equalTo` at a 32-bit key size is 3x faster than `BB.equals` according to MemoryBenchmark. `Memory.copyTo` is another example. Some of the increase is from things that would have been possible to do with BB as well. The key-length-specific hashing and equality code could have been implemented on top of BB. So could the power-of-two optimizations. This actually could get a BB implementation pretty close to a Memory based implementation, but it wouldn't get all of the way there. Even so another justification for using Memory is that IMO the Memory API is better than the ByteBuffer API for the kind of stuff we do. There isn't this position / limit stuff that tends to get in our way. And it doesn't continually reset the byte order to big-endian whenever you duplicate or slice it. The JEP 370 stuff will probably be an even better fit, but it will be a while before we can count on all of our users to have it. For these two reasons (Memory does have a couple of APIs that beat BB, and Memory is a nicer API) I thought going with Memory was a good idea. Btw, Memory still does do bound checks when you enter its code, but once it does them, it uses Unsafe internally. We could be even faster by using Unsafe directly and doing our own bounds checks, but I didn't want to go that far at this time.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
