Request chrome usage of Abseil Multimaps

[Eric Orth]

Found myself needing a multimap in some Chrome code, but I don't think we have any nice container types for doing that without getting into ugliness like base::flat_map<K, std::vector<V>>.  Are there any concerns over allowing usage of absl::btree_multimap and absl::btree_multiset?

I could see there being some objection to the non-multi stuff like absl::btree_map because it's in some ways redundant with stuff we have in base/containers/ and we might want to coordinate a deprecation/migration to avoid the redundancy.  But multi(map/set) has no current equivalent that I know of in Chrome.

One other potential concern I see is that absl::btree_multi(map/set) has a C++17-style extract() method that appears to have some C++17 dependencies (node handles).  Looking at the comments about it in btree_map.h, it looks like it does some different pre-C++17 behavior when compiled with pre-C++17.  I don't think it would be unreasonable to just say that use of that extract() method is disallowed until C++17 and container extract() methods are allowed in Chrome.

[Peter Kasting]

On Thu, Feb 25, 2021 at 1:47 PM Eric Orth <eric...@chromium.org> wrote:

Found myself needing a multimap in some Chrome code, but I don't think we have any nice container types for doing that without getting into ugliness like base::flat_map<K, std::vector<V>>.  Are there any concerns over allowing usage of absl::btree_multimap and absl::btree_multiset?

Is this a case where std::multimap and std::multiset won't work well?

PK 

[Eric Orth]

It's a case where I'm dealing with relatively small maps, so the better-optimized memory usage of base/containers/ or Abseil containers would be ideal.

[Daniel Cheng]

I think it'd be a bit odd to allow btree_multimap but not btree_map.

FWIW, I hope to benchmark absl's map types soon and get some numbers to advocate for switching our default map type to flat_hash_map, but I don't currently have a timeline for that.

Daniel

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMOjQcG86beQMubUBORH%2BWv8XhmrNNiig7pvmO4DWuF%2BHBGnhg%40mail.gmail.com.

[Jan Wilken Dörrie]

On Thu, Feb 25, 2021 at 11:10 PM Daniel Cheng <dch...@chromium.org> wrote:

I think it'd be a bit odd to allow btree_multimap but not btree_map.

+1. If having a space optimized multimap is a pressing issue I'd rather see us introducing base::flat_multi{map,set}. Both the internal gtl::flat_map and the proposed std::flat_map have multi keyed versions.

In general I'd love to see the adoption of abseil's maps, but this should be done carefully.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF3XrKr%3DbdY98H5Lb5v4jBsi5adiCj%2BY4caibXZrt_5hYybC3A%40mail.gmail.com.

[Eric Orth]

On Fri, Feb 26, 2021 at 3:47 AM Jan Wilken Dörrie <jdoe...@chromium.org> wrote:

On Thu, Feb 25, 2021 at 11:10 PM Daniel Cheng <dch...@chromium.org> wrote:

I think it'd be a bit odd to allow btree_multimap but not btree_map.

+1. If having a space optimized multimap is a pressing issue I'd rather see us introducing base::flat_multi{map,set}.

Assuming people agree that the eventual goal is to move to Abseil containers, that would seem to be moving in the wrong direction.

[K. Moon]

I think "inconsistency" would be the wrong direction overall, so I'd rather see this decision share fate with that of the other Abseil containers, not be its own thing.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMOjQcHwjsfaMU9qxc%2Byb2nT-9PZ6CJk19OjHznm3YwFP_h48w%40mail.gmail.com.

[Jan Wilken Dörrie]

On Mon, Mar 1, 2021 at 5:46 PM K. Moon <km...@chromium.org> wrote:

I think "inconsistency" would be the wrong direction overall, so I'd rather see this decision share fate with that of the other Abseil containers, not be its own thing.

Agreed.

 

On Fri, Feb 26, 2021 at 8:25 AM Eric Orth <eric...@chromium.org> wrote:

On Fri, Feb 26, 2021 at 3:47 AM Jan Wilken Dörrie <jdoe...@chromium.org> wrote:

On Thu, Feb 25, 2021 at 11:10 PM Daniel Cheng <dch...@chromium.org> wrote:

I think it'd be a bit odd to allow btree_multimap but not btree_map.

+1. If having a space optimized multimap is a pressing issue I'd rather see us introducing base::flat_multi{map,set}.

Assuming people agree that the eventual goal is to move to Abseil containers, that would seem to be moving in the wrong direction.

Not necessarily. Abseil doesn't export an equivalent of a flat sorted container, so there likely will still be a place for base::flat_(multi)map and *set. Internally these are still recommended for sorted containers that are often read and rarely written. I'd imagine base/containers/README.md will include similar wording in case we decide to adopt the Abseil containers.