gcc/libstdc++-v3/include
Jonathan Wakely db5fa0837e libstdc++: Avoid unnecessary allocations in std::map insertions [PR92300]
Inserting a pair<Key, Value> into a map<Key, Value> will allocate a new
node and construct a pair<const Key, Value> in the node, then check if
the Key is already present in the map. That is because pair<Key, Value>
is not the same type as the map's value_type. But it only differs in the
const-qualification on the Key, and so we should be able to do the
lookup directly, without allocating a new node. This avoids allocating
and then deallocating a node for the case where the key is already found
and nothing gets inserted.

We can take this optimization further and lookup the key directly for a
pair<Key, X>, pair<const Key, X>, pair<Key&, X> etc. for any X. A strict
reading of the standard says we can only do this when we know the
allocator won't do anything funky with the value when constructing a
pair<const Key, Value> from a slightly different type. Inserting that
type only requires the value_type to be Cpp17EmplaceInsertable into the
container, and that doesn't have any requirement that the value is
unchanged (unlike Cpp17CopyInsertable and Cpp17MoveInsertable). For that
reason, the optimization is only done for maps using std::allocator.

A similar optimization can be done for map.emplace(key, value) where the
first argument is similar to the key_type and so can be looked up
without allocating a new node and constructing a key_type.

Finally, both of the insert and emplace cases can use the same
optimization when key_type is a scalar type and some other scalar is
being passed as the insert/emplace argument. Converting from one scalar
type to another won't have surprising value-altering behaviour, and has
no side effects (unlike e.g. constructing a std::string from a const
char* argument, which might allocate).

We don't need to do this for std::multimap, because we always insert the
new node even if the key is already present. So there's no benefit to
doing the lookup before allocating the new node.

libstdc++-v3/ChangeLog:

	PR libstdc++/92300
	* include/bits/stl_map.h (insert(Pair&&), emplace(Args&&...)):
	Check whether the arguments can be looked up directly without
	constructing a temporary node first.
	* include/bits/stl_pair.h (__is_pair): Move to here, from ...
	* include/bits/uses_allocator_args.h (__is_pair): ... here.
	* testsuite/23_containers/map/modifiers/emplace/92300.cc: New test.
	* testsuite/23_containers/map/modifiers/insert/92300.cc: New test.
2021-12-09 22:56:57 +00:00
..
backward
bits libstdc++: Avoid unnecessary allocations in std::map insertions [PR92300] 2021-12-09 22:56:57 +00:00
c
c_compatibility
c_global libstdc++: Enable type traits for wchar_t unconditionally [PR98725] 2021-10-09 00:57:49 +01:00
c_std
debug libstdc++: Define std::__is_constant_evaluated() for internal use 2021-12-01 15:00:33 +00:00
decimal
experimental libstdc++: Fix non-reserved name in std::allocator base class [PR64135] 2021-12-09 22:50:10 +00:00
ext libstdc++: Fix non-reserved name in std::allocator base class [PR64135] 2021-12-09 22:50:10 +00:00
parallel
precompiled libstdc++: Implement std::spanstream for C++23 2021-11-13 11:45:31 +00:00
pstl
std libstdc++: [_GLIBCXX_DEBUG] Enhance std::erase_if for vector/deque 2021-12-08 19:09:47 +01:00
tr1 libstdc++: Enable type traits for wchar_t unconditionally [PR98725] 2021-10-09 00:57:49 +01:00
tr2
Makefile.am libstdc++: Fix non-reserved name in std::allocator base class [PR64135] 2021-12-09 22:50:10 +00:00
Makefile.in libstdc++: Fix non-reserved name in std::allocator base class [PR64135] 2021-12-09 22:50:10 +00:00