)]}'
{
  "commit": "b751a977cb15f43599e541d38fa65df87a7f5a1b",
  "tree": "95152cb74a6b584577b1f15ed9c1cedf37eb9a2f",
  "parents": [
    "562cc25fec0b71ad1e277317deb417421b46d440"
  ],
  "author": {
    "name": "Sunny Young de la Sota",
    "email": "myoung@buf.build",
    "time": "Thu Aug 20 00:54:11 2026 -0700"
  },
  "committer": {
    "name": "Gopher Robot",
    "email": "gobot@golang.org",
    "time": "Mon Aug 24 10:09:43 2026 -0700"
  },
  "message": "internal/runtime/maps: tune MinAeshashSize for arm64\n\nSet the cutoff to 16 bytes on arm64, measured on my Apple M1 Max.\nThis is the throughput regime cross-over point.\n\n16 is the value that popped out of the bakeoff benchmark I added.\nUnlike with x86, where we picked 9, sizes from 9 to 15 want to go\nthrough wyhash on ARM.\n\nAs with my x86 benchmarks, the throughput and latency cutoffs are\nvery different. I observed a cross-over for latency at 192, which\nmay be worth exploring in the future (see go.dev/issue/80970).\n\nBenchmarks below are linker-randomized and interleaved to shake\nout code layout and thermal drift issues (total n\u003d18).\n\n    MapGroupBy/Key\u003dint64                4.73m   1.65m  -65.1%\n    Hash5                               5.52n   3.24n  -41.3%\n    ComplexAlgMap                      23.98n  17.86n  -25.5%\n    MapAssignExists/int64/len\u003d6         6.00n   4.85n  -19.2%\n    MapCycle                           19.75n  16.23n  -17.8%\n    MapAssignExists/int64/len\u003d65536    10.07n   8.48n  -15.8%\n    MapGroupBy/Key\u003dstring               3.15m   2.69m  -14.6%\n    MapAssignFillHint/int64/len\u003d65536  16.05n  14.15n  -11.8%\n    MapAccessHit/int64/len\u003d65536        8.82n   7.91n  -10.3%\n    MapAccessMiss/int64/len\u003d65536       8.12n   7.36n   -9.4%\n    MapDelete/int64/len\u003d65536          51.91n  48.40n   -6.8%\n    HashStringSpeed                     8.30n   7.78n   -6.4%\n    MapAccessHit/string/len\u003d65536      12.38n  11.88n   -4.0%\n    MapAccessHit/int64/len\u003d6            4.47n   4.43n       ~\n    Hash16                              2.92n   2.90n       ~\n    Hash64                              4.02n   4.02n       ~\n    MapPopulate/1000                   41.14µ  43.25µ   +5.1%\n    MapPop/Key\u003d*int32/len\u003d65536          241n    271n  +12.4%\n    MapPop/Key\u003dint32/len\u003d65536           216n    255n  +18.2%\n    MapPop/Key\u003dint64/len\u003d65536           222n    273n  +23.1%\n\nEverything not shown did not change. Geomean is -3.8%. Yes, that is\na statistically-significant 65% improvement for the aggregation\nbenchmark I added.\n\nNow, this is not pure gains, because MapPop regressed by around 20%.\nThis checks the performance of \"grab a random element and delete it\".\nThis benchmark is very old and is a backstop against quadratic behavior\nof the pre-swiss implementation. The regression is not ideal, but I\nthink this is a rare type of map operation, and I think it\u0027s fine to\ntrade it off given how many other benchmarks improved.\n\nChange-Id: I6a34322155e9a39e6f4cbd8a617dc9202a38ef52\nReviewed-on: https://go-review.googlesource.com/c/go/+/818500\nAuto-Submit: Keith Randall \u003ckhr@golang.org\u003e\nReviewed-by: Keith Randall \u003ckhr@google.com\u003e\nReviewed-by: Keith Randall \u003ckhr@golang.org\u003e\nLUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com \u003cgolang-scoped@luci-project-accounts.iam.gserviceaccount.com\u003e\nReviewed-by: Michael Pratt \u003cmpratt@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "cfe4a56001438a515190c38e2378271f4a8d6b1c",
      "old_mode": 33188,
      "old_path": "src/internal/runtime/maps/runtime_alg.go",
      "new_id": "ca16b64a74e218d1b58d2a55d7801f4ae440c82e",
      "new_mode": 33188,
      "new_path": "src/internal/runtime/maps/runtime_alg.go"
    }
  ]
}