[libcxx] Avoid hash key in __hash_table::find() if it is empty. #126837
Conversation
If the hash table has no buckets yet, it's empty and the find will do fast return end(). Then compute hash key is useless and can be avoided, since it could be expensive for some key types, such as long string. This is a small optimization but useful in cases like a checklist ( implemented as unordered_set) that is mostly empty.
|
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
|
@llvm/pr-subscribers-libcxx Author: None (xbcnn) ChangesIf the hash table has no buckets yet, it's empty and the find will do fast return end(). Then compute hash key is useless and can be avoided, since it could be expensive for some key types, such as long string. This is a small optimization but useful in cases like a checklist ( implemented as unordered_set) that is mostly empty. Full diff: https://github.com/llvm/llvm-project/pull/126837.diff 1 Files Affected:
diff --git a/libcxx/include/__hash_table b/libcxx/include/__hash_table
index d7b312f8774fc..a1d06d07f7c8d 100644
--- a/libcxx/include/__hash_table
+++ b/libcxx/include/__hash_table
@@ -1771,9 +1771,9 @@ template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::find(const _Key& __k) {
- size_t __hash = hash_function()(__k);
size_type __bc = bucket_count();
if (__bc != 0) {
+ size_t __hash = hash_function()(__k);
size_t __chash = std::__constrain_hash(__hash, __bc);
__next_pointer __nd = __bucket_list_[__chash];
if (__nd != nullptr) {
@@ -1792,9 +1792,9 @@ template <class _Tp, class _Hash, class _Equal, class _Alloc>
template <class _Key>
typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::const_iterator
__hash_table<_Tp, _Hash, _Equal, _Alloc>::find(const _Key& __k) const {
- size_t __hash = hash_function()(__k);
size_type __bc = bucket_count();
if (__bc != 0) {
+ size_t __hash = hash_function()(__k);
size_t __chash = std::__constrain_hash(__hash, __bc);
__next_pointer __nd = __bucket_list_[__chash];
if (__nd != nullptr) {
|
|
This is my first PR to the LLVM project. Please help to review and comments if any problem. |
|
First thanks for reviews.
Sure, but I probably need some guides such as where to put the benchmark src and how to build/run it. |
Benchmarks are in |
|
I add a separate benchmark: I pre-generate 32K random strings(each 32-128 characters long), and do find iteration ranging from 1024~32768. With the opt: Without the opt: On empty set, it's about 10+ times gains since no hash key computed. |
|
I think we could update |
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
|
We could go ahead to double check |
|
Updated benchmarks: Opt with size() check No opt |
|
Hi @philnik777 @ldionne @frederick-vs-ja I've added |
|
Hi @philnik777 @frederick-vs-ja |
| @@ -0,0 +1,97 @@ | |||
| //===----------------------------------------------------------------------===// | |||
There was a problem hiding this comment.
Please update associative_container_benchmarks.h to include zero-sized benchmarks (where appropriate) instead.
| @@ -1771,9 +1771,9 @@ template <class _Tp, class _Hash, class _Equal, class _Alloc> | |||
| template <class _Key> | |||
| typename __hash_table<_Tp, _Hash, _Equal, _Alloc>::iterator | |||
There was a problem hiding this comment.
Not attached to this file: Please add the before/after benchmarks in the commit message.
If the hash table has no buckets yet or it's empty, the find should do fast return end(). Then computing hash key is useless and can be avoided, since it could be expensive for some key types, such as long string.
This is a small optimization but useful in cases like a checklist ( implemented as unordered_set/map) that is mostly empty.