After switching to the toolchain v5 as default in 341832a we've observed few performance regressions including a 10% regression in ElemMatchLargeMixedInAndOrWithDuplicates causing BF-37502.

The benchmark in question executes a simple find query with nested $elemMatch, $or, and $in predicates. Both $or and $in predicates have many arguments. The benchmark targets SBE engine (not yet enabled by default) which uses absl::raw_hash_set for $in predicate implementation.

Our initial investigation identified >10% regressions in absl::raw_hash_set::find() (SERVER-104956) and in sbe::vm::ByteCode::runInternal() (this ticket). After disassembling sbe::vm::ByteCode::runInternal() we saw 25% more instructions in v4 binary which might indicate at more aggressive code in-lining. On the other hand, v4 contains 172 more branching instructions pointing at some other possible optimization. Current hypothesis - we are dealing with different switch statement optimizations.

The goal of this ticket is to identify relevant compile-time optimization in v4 vs. v5 toolchain for this particular workload and suggest or force it on sbe::vm::ByteCode::runInternal().