[PATCH] D48896: [libcxx][c++17] P0083R5: Splicing Maps and Sets Part 2: merge

Richard Smith - zygoloid via Phabricator reviews at reviews.llvm.org
Wed Oct 24 14:06:29 PDT 2018


rsmith added a comment.

In https://reviews.llvm.org/D48896#1274919, @rsmith wrote:

> In https://reviews.llvm.org/D48896#1274779, @ldionne wrote:
>
> > When merging  a multi-container into a unique-container (e.g. `map.merge(multimap)` or `set.merge(multiset)`), I think we could do the following optimization: Once we've inserted an element from the `multimap` into the `map`, we could skip all the following equivalent elements in the `multimap` without having to perform a search in the `map` each time (since we know we won't insert the element anyway).
>
>
> We can only do that if the comparators divide elements into the same equivalence classes, which we cannot know in general. (We can do this optimization if we can prove the comparator is a pure stateless function, but we probably can't detect that -- even an empty class type could store its state outside the class.) However, if the source and destination have the same comparator, and that comparator is `std::less<T>`, then I think it's correct to do this optimization.


Hmm, actually, we can probably do this in more cases than that. If we use the *destination's* comparator to check for equivalent elements instead of the source's comparator (under the assumption that the destination order is usually the same as the source order), this would work. But more generally, can we just provide the location of the most-recently-inserted element as an insertion hint and get this optimization as a special case of a more general optimization? But maybe that's actually what you were suggesting (the difference is hidden behind the "key in the source is not equivalent to the [other] key" comments -- equivalent according to which comparator?).


https://reviews.llvm.org/D48896





More information about the libcxx-commits mailing list