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

Reduce number of allocations for plan stage children container

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Trivial - P5 Trivial - P5
    • 8.1.0-rc0
    • Affects Version/s: None
    • Component/s: Query Execution
    • None
    • Query Execution
    • Fully Compatible
    • QE 2025-02-03
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      The PlanStage::Children type is currently defined as an std::vector<std::unique_ptr<PlanStage>> here.
      Plan stages insert their child stage pointers into this vector, often in the stage constructors.
      Most stages have a single child, but some stages also have multiple children.
      The initial insert of one stage into each stage's _children member will cause a heap memory allocation and increase the vector's capacity to 1. Inserting a second stage will cause another heap allocation and increase the capacity to 2. Inserting another stage will cause another heap allocation and increase the capacity to 4.
      These heap allocations could be saved by turning PlanStage::Children into an absl::InlinedVector<std::unique_ptr<PlanStage>> with a big enough inline capacity to handle the majority of cases without performing heap allocations.
      It seems that an inline capacity of 4 stages will help for the majority of stages. It won't help much for stages with a high number of children, but it will save the initial few heap allocations there too.
      No visible performance improvements are expected by making this change, but as stage creation should be on the hot path of all executed queries, it still looks like it is worth doing.

            Assignee:
            jan.steemann@mongodb.com Jan Steemann
            Reporter:
            jan.steemann@mongodb.com Jan Steemann
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              None
              None
              None
              None