Preliminary results were posted in https://docs.google.com/spreadsheets/d/1xYiEZlqL9tukSgZENvZIxgIHxrwo7c_PKFDdXCP6QkA/edit#gid=5. These may be fairly old, but we should look into the replication-related regressions until newer results are ready. These may or may not be false positives. In no particular order:

• kvserver/ReplicaProposal @pavelkalinnikov
  • clusterversion: benchmark and rm Unmarshal allocs #113043
  • kvserver: do lazy map allocations in replicaFlowControl #113150
  • kv,server,roachpb: avoid error overhead for x-locality comparison #113229
  • logstore: pool MVCCStats to avoid hot path allocs #113742
  • Performance diff is within a reasonable error margin.
• kvserver/BumpSideTransportClosed @erikgrinaker
  • 15% regression, unknown cause, small in absolute terms
  • Benchmark sensitive to Go runtime: regressed from 220ns on 1.19 to 250ns on 1.20; went back to 220ns on 1.21.
• kvserver/raftentry/EntryCache @pavelkalinnikov
  • single-digit % CPU regression. Hard to attribute to anything except Go runtime changes
  • Quite a bit more time spent in raftpb.(*Entry).Size(): 3.62s -> 4.48s
• kvserver/raftentry/EntryCacheClearTo @pavelkalinnikov
  • Same as kvserver/raftentry/EntryCache
  • Particularly, more time is spent in proto size computation
• kvserver/logstore/LogStore_StoreEntries @pavelkalinnikov
  • clusterversion: benchmark and rm Unmarshal allocs #113043
  • One more finding, fixed in logstore: pool MVCCStats to avoid hot path allocs #113742.
• kvserver/StoreRangeMerge @erikgrinaker
  • ~10% allocs/op increase, but highly unreliable -- alloc/op and time decreased, and we don't particularly care about allocs/op here anyway.
  • @pavelkalinnikov measured after all the fixes. Allocations dropped to roughly level; but the 23.1 measurement is unreliable. CPU is still up by a couple of percent, but that's probably fine.
• kvserver/closedts/tracker/HeapTracker @erikgrinaker
  • fixed in recent benchmarks

Jira issue: CRDB-31969