Background

SERVER-130854 (c70a5b8) made ExpressionObject evaluation account memory unconditionally: mongo::exec::expression::evaluate now resolves a tracker via getMemoryTracker(), which falls back to a query-scoped tracker when ctx.tracker is null, so the per-document memory bookkeeping runs on every document instead of only when a stage wired in a tracker.

This is correct behavior, but it introduced a measurable per-document CPU cost on expression-heavy aggregation hot paths, tracked in BF-44592 (regressions of ~14% AverageLatency on tsbs_steady_state_low lastpoint and ~22% Latency50th on time_series_lastpoint).

Where the cost is

On-CPU profiling (causal commit vs parent) showed the added cost is the tracker bookkeeping itself, run per document:

• SimpleMemoryUsageTracker::add — the dominant added cost (~+4.5 percentage points of on-CPU time in the indexed lastpoint query phases).
• SimpleMemoryUsageTracker::assertWithinMemoryLimit — 0.00% in the parent build, present after the commit.
• getApproximateSize — flat; the size estimate is not the cost.

Reached through two paths: directly via ExpressionObject::evaluate (document-literal $group _id), and via AccumulatorTopBottomN output-expression evaluation when the lastpoint optimization rewrites $first/$last into $top/$bottom.

Scope of work

Reduce the per-document memory-tracking overhead in expression evaluation without regressing memory-limit correctness. Confirm the fix on the hot paths exercised by tsbs_steady_state_low (lastpoint) and time_series_lastpoint (indexed RunLastPointQuery).

Validation

Re-run the affected tasks on perf-3-node-replSet.arm.aws.2024-05 and confirm AverageLatency / Latency50th return toward the pre-SERVER-130854 baseline.