Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-88448

Use cheaper containers in collection acquisition path

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing
    • Fully Compatible
    • CAR Team 2024-04-01

      The acquireCollection() path uses maps and vectors to general-case the least-likely cases of collection acquisition. In most cases, these containers contain one item, but we're paying the cost for the worst case.

      Ideally, we would refactor this code to fast-path the single-collection cases, but since that's hard, we should just try to use cheaper containers.

      Ideas:

      • Replace std::vector in the acquisitionRequests with absl::InlinedVector, which optimizes for the case of a small number of elements. The constructor lets us pre-allocate the vector with a single element in the common case.
      • Replace stdx::unordered_map in the CollectionAcquisitions (which uses absl::node_hash_map) with absl::flat_hash_map which is more memory-efficient.
      • Replace std::list in TransactionResources to use absl::InlinedVector. It's not clear that we need linked-list semantics here.
      • Replace ResolvedNamespaceOrViewAcquisitionRequestsMap with a absl::InlinedVector. In the most common case, this should only be 1 element. It's also not immediately obvious that we need this to have constant-time lookup, but it does appear to need to be sorted. If we need to sort this in the multi-collection case, it would probably be cheaper to use std::sort once we've made all of the acquisition requests, rather than maintain a full tree data structure.

        1. map.png
          map.png
          521 kB
        2. node_hash_map.png
          node_hash_map.png
          522 kB
        3. perf-test_phase-0002_flamegraph_connections_merged.svg
          935 kB
        4. vector.png
          vector.png
          523 kB

            Assignee:
            louis.williams@mongodb.com Louis Williams
            Reporter:
            louis.williams@mongodb.com Louis Williams
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: