gh-150638: Improve performance of json.loads and json.load for numeric data

[eendebakpt]

_match_number_unicode() (the C accelerator behind json.loads) previously allocated a PyBytes object for every number, copied the digits into it, and then called the generic PyLong_FromString / PyFloat_FromString parsers.
This PR parses the common cases directly from the already-scanned text.

Benchmark	main	this PR	speedup
json.loads, number-heavy document (script below)	3.05 ms	2.38 ms	1.28×
json.load, same document via file object	3.17 ms	2.48 ms	1.28×
pyperformance bm_json_loads	25.2 µs	23.9 µs	1.05×

The standard bm_json_loads document is string/dict-dominated, so it gains
less.

Also addresses #155742

Benchmark script

"""Benchmark json.loads() and json.load() on a number-heavy document.

The document is generated deterministically at import time (no external
files) and resembles a typical telemetry/API payload: a list of records
mixing integers, 19-digit timestamps, negative integers, floats, short
strings, booleans and small integer arrays.

json.load(fp) is json.loads(fp.read()); here fp is an in-memory io.StringIO
(rewound each call) so the same document is parsed without disk noise.

Inline data size: ~304 KiB (2000 records).
"""
import io
import json
import pyperf


def build_document(n=2000):
    return [
        {
            "id": i,
            "timestamp": 1_700_000_000_000_000_000 + i * 1_000,  # 19-digit int
            "value": i * 1.5 - 1000.0,                           # float
            "delta": -i,                                         # negative int
            "label": "item-%d" % i,                              # short string
            "ok": i % 2 == 0,                                    # bool
            "samples": [i, -i, i * 2, i * 3, i * 5],             # int array
        }
        for i in range(n)
    ]


JSON_DATA = json.dumps(build_document())
STREAM = io.StringIO(JSON_DATA)


def load_from_stream():
    STREAM.seek(0)
    return json.load(STREAM)


if __name__ == "__main__":
    runner = pyperf.Runner()
    runner.metadata["description"] = "json.loads()/json.load() on a number-heavy document"
    runner.bench_func("json_loads", json.loads, JSON_DATA)
    runner.bench_func("json_load", load_from_stream)

• Issue: Improve performance of json.loads and json.load for numeric data #150638

[markshannon]

Looks good, but the wide scope of numstr makes it a bit hard to reason about refleaks.

Can you remove the early declaration of numstr and define it where you need it.

[markshannon]

numstr is only defined on lines 1068 and 1108.
You could declare it only in those places, and decref it in the same blocks.

[kumaraditya303]

this can use _PyLong_Negate

[eendebakpt]

_PyLong_Negate is define in longobject.c and not part of the internal API. I do not think it is worth it here to expose.

If we change idx - start - neg <= 19 into idx - start - neg <= 18 we can fit value into a signed long and negate value (but we loose the fast path for values with 19 digits). There are a few more tricks we could do, but I think the performance gain would not be enough to warrant the extra complexity.

[sprajs]

Reviewed c14d8063e303475af844b3e291c9622b023bd036 against merge base 7aec160315a6316f7391abda10d4b6c57032d105.

No correctness regression reproduced in 5,252 C-versus-Python-scanner cases, 24 exact-token custom-hook checks, and 400 allocation-failure offsets. These cover 19/20-digit and signed/unsigned boundaries, negative zero, subnormal/overflow cases, exponent extremes, long buffers, 1/2/4-byte Unicode inputs and conversion limits. The shared debug-runtime comparison passes 237 JSON tests (3 skipped), plus all 46 tests in this PR's exact test_decode module on both variants.

I compared the two overlapping proposals using one PGO/LTO core built from #156897's head. The baseline _json.c sources are identical; each of baseline, #156897 and #150639 was compiled with the same -O3 flags and headers, without module-specific PGO. This isolates the decoder components:

Workload	base	156897	150639
float_array_10000	1.96 ms	1.89 ms	1.75 ms
numeric_records_2000	1.65 ms	1.63 ms	1.52 ms
pyperformance_json_loads	20.00 µs	19.88 µs	19.00 µs

Inputs: 10,000 successive random() calls on one Random(156897) instance (the float-array workload from #156897's discussion, with a fixed seed); 2,000 records with integer IDs, two floats and a boolean; and the three-object pyperformance json_loads fixture. The latter is timed with its original 20-call unrolling and normalization. #156897 still allocates the intermediate character buffer; #150639 additionally provides integer and stack-buffer fast paths.

Timings are medians from seven interleaved fresh processes on Linux x86-64, i9-9900K/GCC 16.2.1, pinned to one logical CPU; GC disabled during timed loops, hash seed 0, calibration to 65 ms followed by a separately timed batch. Builds and tests had finished before timing; the desktop was not frequency-isolated. These are workload-specific measurements, not application-wide speedups.

Review and testing performed with Codex (AI assistance).