)]}'
{
  "commit": "b64d014e2f3f83fc8a930a9c420243b2e85bec57",
  "tree": "cd6ef9a17868d98c72da5eb7668ccde6b2288192",
  "parents": [
    "7790aa6231b8f81bef1f31e48b5ff06f65a14403"
  ],
  "author": {
    "name": "fcostaoliveira",
    "email": "filipe@redis.com",
    "time": "Sun May 31 23:48:45 2026"
  },
  "committer": {
    "name": "fcostaoliveira",
    "email": "filipe@redis.com",
    "time": "Mon Jun 01 08:55:08 2026"
  },
  "message": "Unroll the integer-part digit scan (straight-line for the common 1-5 digit case)\n\nparse_number_string scans the integer part one byte at a time in a while loop,\nwhile the fraction already uses the 8-digit SWAR loop. Most integer parts are\n1-5 digits, so the loop back-edge dominates. Peel the first five iterations into\nnested ifs, falling through to the original while for longer runs. Semantics are\nidentical (i \u003d 10*i + digit, advancing p); no behavior change.\n\nAWS m8g.metal-24xl (Graviton4), -O3 -march\u003dnative, simple_fastfloat_benchmark,\nfrom_chars-\u003edouble. base vs patch measured back-to-back, mean of 2 runs:\n  canada: gcc +3.1%, clang +2.8%\n  mesh:   gcc +5.4%, clang +5.1%\n  random: ~flat (1-digit integer part)\nNo regression; gcc and clang agree.\n\nAlternatives benchmarked and rejected: reusing loop_parse_if_eight_digits for the\ninteger part regressed 5-8% (integer parts are too short for 8-digit SWAR setup);\na counted for(k\u003c5) loop matched on gcc but clang optimized it worse (canada -0.9%).\nThe explicit peel is the only form solidly positive on both compilers.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "12c2fddcd3bced1364176daeb3b08b85c73f4595",
      "old_mode": 33188,
      "old_path": "include/fast_float/ascii_number.h",
      "new_id": "22816eccf33175e7719db24692677312e2fa5f04",
      "new_mode": 33188,
      "new_path": "include/fast_float/ascii_number.h"
    }
  ]
}