suneet-s opened a new pull request #10313: URL: https://github.com/apache/druid/pull/10313
### Description Change the default numeric hashing threshold to 1 and make it configurable. Benchmarks attached to this PR show that binary searches are not more faster than doing a set contains check. The attached flamegraph shows the amount of time a query spent in the binary search. Given the benchmarks, we can expect to see roughly a 2x speed up in this part of the query which works out to ~ a 20% faster query in this instance. <img width="1668" alt="Screen Shot 2020-08-23 at 10 38 55 PM" src="https://user-images.githubusercontent.com/44787917/91008091-72122880-e592-11ea-9b88-e9d9943201d6.png";> In this flamegraph, a query is taking ~40% of the time doing a binary search on 4 numbers. The query I used is not very selective, so it has to do the binary search many times. I see a comment on `NUMERIC_HASHING_THRESHOLD` that talks about benchmarks, but I couldn't find any in the codebase, so I wrote my own hacky ones, just to get a sense for the breaking points. The benchmarks probably need a lot of work, and the results should be taken with a grain of salt because I ran most of them only 10 times to calculate the average time. I tried 3 algorithms: binary search, set contains and a linear search (using LongArraySet as a proxy) Here's a summary of the results. The results are in ns / operation with a 20% match rate with the match being chosen at random within the list of filter values. Algorithm | 16 | 8 | 4 | 2 | ---------- | -- |-- | -- | -- | BinarySearch | 7.883 | 4.451 | 3.750 | 4.71 LongOpenHashSet | 3.086 | 3.142 | 3.071 | 4.02 LongArraySet | 9.856 | 6.077 | 4.151 | 3.28 I then ran the benchmarks to compare the worst and best case match times for 16 elements in the set Algorithm | Worst | Best ---------- | -- |-- BinarySearch | 5.401 | 2.991 LongArraySet | 10.985 | 2.908 These numbers seem to indicate that the performance gain of not using a set contains is minimal, even with very small sets and will depend on the number of elements in the dataset that will match the filter. These numbers seem to indicate that the contains time is relatively consistent at ~ 3.1 ns / op whereas a binary search operation is almost 2ns per op slower. Based on these numbers, I suspect the query above would see ~ 10% gain by switching to using the LongOpenHashSet instead of a binary search, while queries with in filters closer to 16 values would see a bigger benefit. <hr> This PR has: - [ ] been self-reviewed. - [ ] using the [concurrency checklist](https://github.com/apache/druid/blob/master/dev/code-review/concurrency.md) (Remove this item if the PR doesn't have any relation to concurrency.) - [ ] added documentation for new or modified features or behaviors. - [ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links. - [ ] added or updated version, license, or notice information in [licenses.yaml](https://github.com/apache/druid/blob/master/licenses.yaml) - [ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader. - [ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for [code coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md) is met. - [ ] added integration tests. - [ ] been tested in a test Druid cluster. <!-- Check the items by putting "x" in the brackets for the done things. Not all of these items apply to every PR. Remove the items which are not done or not relevant to the PR. None of the items from the checklist above are strictly necessary, but it would be very helpful if you at least self-review the PR. --> <hr> ##### Key changed/added classes in this PR * `MyFoo` * `OurBar` * `TheirBaz` ---------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
![https://user-images.githubusercontent.com/44787917/91008091-72122880-e592-11ea-9b88-e9d9943201d6.png"](https://user-images.githubusercontent.com/44787917/91008091-72122880-e592-11ea-9b88-e9d9943201d6.png"){kind=link}