Benchmark and test changes to vector pre-filling in BSONIteratorSorted

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Service Arch
    • Fully Compatible
    • Service Arch 2024-04-01
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      In a recent change to BSONIteratorSorted, we changed from using a raw array to a vector. In doing so, we pre-allocate the space for that vector, tapping into the nFields BSONObj function to get the number of fields. This function scans the BSONObj. We then, later, scan the BSONObj again to fill in the vector.

      It's possible to forgo a scan and not preallocate space in the vector. But it's a tradeoff. What has worse performance, scanning a BSONObj or constructing a vector item-by-item?

      We should benchmark this and see if it's worth changing.

      Also, we use .at() which is strictly worse performance than [] to access items.

      ivan.fefer@mongodb.com gets credit for finding this!

            Assignee:
            Erin McNulty
            Reporter:
            Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: