[libc++] Optimize __tree::find and __tree::__erase_unique#152370
[libc++] Optimize __tree::find and __tree::__erase_unique#152370philnik777 merged 1 commit intollvm:mainfrom
Conversation
|
@llvm/pr-subscribers-libcxx Author: Nikolas Klauser (philnik777) ChangesFull diff: https://github.com/llvm/llvm-project/pull/152370.diff 1 Files Affected:
diff --git a/libcxx/include/__tree b/libcxx/include/__tree
index 6ca1a623536f2..1a3d4afa2d8fc 100644
--- a/libcxx/include/__tree
+++ b/libcxx/include/__tree
@@ -2062,10 +2062,11 @@ template <class _Tp, class _Compare, class _Allocator>
template <class _Key>
typename __tree<_Tp, _Compare, _Allocator>::size_type
__tree<_Tp, _Compare, _Allocator>::__erase_unique(const _Key& __k) {
- iterator __i = find(__k);
- if (__i == end())
+ __end_node_pointer __parent;
+ __node_base_pointer __i = __find_equal(__parent, __k);
+ if (__i == nullptr)
return 0;
- erase(__i);
+ erase(iterator(static_cast<__node_pointer>(__i)));
return 1;
}
|
03855dd to
e774294
Compare
e774294 to
1995180
Compare
1995180 to
fc6edb7
Compare
fc6edb7 to
34e9a72
Compare
Should that go in the release notes as well? |
|
We have this function that tries to find all bookmark nodes with a given URL:
The whole thing as a standalone repro (the .sh is meant to run on a mac; needs minor tweaks to run on linux): From what I understand, our code is incorrect, and we should use e.g. (But, see question in the comment above please :)) |
Yes, this should probably be release noted. I'll make a patch.
Yeah, this looks incorrect to me. You want to either use |
|
Doesn't this also affect While I may misunderstand the (we have just started seeing unexpected test failures on the Apache Arrow CI because of this) |
|
(downstream Arrow issue for reference: apache/arrow#49586) |
|
@ldionne @philnik777 Could you comment on the above comment? Do you think I should open a separate issue for it? |
This patch changes
__tree::findto return when it has found any equal element instead of the lower bound of the equal elements. Formapandsetthere is no observable difference, since the keys are unique. However for theirmultiversions this can mean a change in behaviour since it's not longer guaranteed thatfindwill return the first element.