About half of the regression is due to known issue SERVER-82641, where there are currently two ProjectStages if the array index is requested. This microbenchmark is executing pipeline

[\{$unwind: {path: "$array", includeArrayIndex: "index"}}]

against documents of the form

{_id: i, array: [1, "some string data", new ObjectId(), null, NumberLong(23), [4, 5], {x: 1}]}

* On my arm64 VWS an optimized build achieves about 275 ops/sec on this.

• Removing the "includeArrayIndex" piece increases this to about 410 ops/sec.

(410 - 275) / 410 * 100 = 33% regression from the extra ProjectStage, which makes a second copy of the output document.

The second half of the BF regression is probably from ProjectStage being slow in general in SBE, as thesew mostly run in the VM, not native C++, and write projections always make a new copy of the output document. These things are probably not fixable in SBE without writing a new variant of ProjectStage that does not suffer from these issues, since the $unwind at minimum needs one read ProjectStage to get its inputs and one write ProjectStage to add its outputs to the result doc.

UnwindStage itself runs in native C++ but does not do very much work. Most of the work of any $unwind in SBE is due to ProjectStage.

Keeping this ticket open for the time being to look into handling this second half of the regression.