[RESP] Fix InlinePing SIMD-scan regression and MGET per-key boxing allocation - #1988

Summary

Two independent performance fixes for regressions surfaced by the BDN CI benchmarks, both in libs/server/Resp/. Split into two commits (one per fix).

1. InlinePing SIMD-scan regression — RespCommand.cs

Root cause: #1658 added an unconditional SIMD Vector128 scan at the top of FastParseCommand, gated only on remainingBytes >= 16. Every SIMD pattern is RESP array-framed (*N\r\n$L\r\nCMD\r\n), so an inline command such as PING\r\n (starts with a command letter, not *) can never match. In a batched inline workload the buffer is always ≥ 16 bytes, so each inline command paid a NoInlining call plus ~18 vector comparisons before falling through to FastParseInlineCommand.

Fix: Gate the SIMD scan on a leading *. Inline commands skip it and go straight to FastParseInlineCommand (pre-#1658 behavior). This loses no SIMD matches (all patterns require *) and adds only a single byte compare to the array-framed hot path.

Measured — Operations.BasicOperations.InlinePing (None), net10.0:

Array-framed commands (GetNotFound/GetFound) verified unaffected.

2. MGET per-key struct boxing allocation — MGetReadArgBatch.cs

Root cause: MGetReadArgBatch_SG is a struct implementing IReadArgBatch, whose InitialIORecordSize and ReadCopyOptions are default interface methods. The struct did not implement them, so calling them through the generic TBatch constraint in ContextReadWithPrefetch boxed the struct on every call. InitialIORecordSize is read once per key in the read loop, so a 100-key MGET boxed 100× (plus one box for ReadCopyOptions) → 4848 B allocated per MGET, tripping the BDN allocation gate (expected 0) for Cluster.ClusterOperations.MGet and Cluster.ClusterMigrate.MGet.

Fix: Explicitly implement both members on the struct (returning the same values as the interface defaults) so the calls bind directly and no longer box. This matches the existing VectorReadBatch implementation.

Measured: MGet allocation 4848 B → 0 B; mean also improves ~13.3 → 11.95 µs.

Key technical details

Affected types:

• RespServerSession.FastParseCommand (libs/server/Resp/Parser/RespCommand.cs)
• MGetReadArgBatch_SG : IReadArgBatch (libs/server/Resp/MGetReadArgBatch.cs)

Both fixes are behavior-preserving: identical parse results, and the MGET members return the same values as the interface defaults.

What NOT to do (for future agents)

• ❌ Don't run the SIMD command scan for buffers that aren't *-framed — inline commands can never match array-framed patterns, so the scan is pure overhead.
• ❌ Don't rely on IReadArgBatch default interface members from a struct batch — calling a default interface method on a value type through a generic constraint boxes it (once per call). Implement the members explicitly.

Testing

• RespTests (347), RespParseFuzzRegressionTests (4), and RespGetLowMemoryTests.ScatterGatherMGet (disk/async completion, 30/300/3000 keys) all pass.
• BDN: InlinePing recovered to ~pre-[RESP] Optimize command parsing with SIMD fast path and O(1) hash table lookup #1658; ClusterOperations.MGet / ClusterMigrate.MGet allocation now 0.
• dotnet format --verify-no-changes clean; Release build has no new warnings.

Issues Fixed

These regressions were surfaced by the BDN charts / CI perf gate rather than tracked issues. Link an issue here if one exists.