gh-150638: Improve performance of json.loads and json.load for numeric data by eendebakpt · Pull Request #150639 · python/cpython · GitHub

_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

Add a fast path to _match_number_unicode for integers that fit in a 64-bit integer (at most 19 decimal digits): accumulate the value directly into an unsigned long long instead of allocating a PyBytes and calling the generic PyLong_FromString. Positive values use PyLong_FromUnsignedLongLong; negatives within long long range use PyLong_FromLongLong; larger integers fall back to the previous path. For floats and big integers, copy the (always-ASCII) number text into a stack buffer for the common short case to avoid the PyBytes allocation, and call PyOS_string_to_double directly for floats. Benchmarks (optimized free-threaded build): * pyperformance json_loads: 1.06x faster overall * microbench: small int arrays ~2x, 20-int doc 1.48x, mixed dict 1.16x All test_json tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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.

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

this can use _PyLong_Negate

_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.

I implemented it like this:

n = idx - start;
if (!is_float && n <= 19) {
    if (PyUnicode_READ(kind, str, start) == '-') {
        /* integer with at most 18 digits (excluding sign) fits in
            long long (10 ** 18 - 1 <= 2 ** 63 < 10 ** 19 - 1) */
        long long value = 0;
        for (i = start + 1; i < idx; i++) {
            value = value * 10 - (PyUnicode_READ(kind, str, i) - '0');
        }
        return PyLong_FromLongLong(value);
    }
    else {
        /* integer with at most 19 digits fits in unsigned long
            long (10 ** 19 - 1 <= 2 ** 64 - 1 < 10 ** 20 - 1) */
        unsigned long long value = 0;
        for (i = start; i < idx; i++) {
            value = value * 10 + (PyUnicode_READ(kind, str, i) - '0');
        }
        return PyLong_FromUnsignedLongLong(value);
    }
}

Nice! If we have - we are guaranteed to have one digit less, so we fit into a long long.

# Conflicts: # Lib/test/test_json/test_decode.py

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).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Avoids the PyNumber_Negative call: a negative literal of at most 19 characters has at most 18 digits, which always fits in a long long. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

@kumaraditya303 Could you review again? I made two minor updates: the suggestion by nineteendo to avoid to negation and avoid mutation of bytes objects.

Could you credit me? Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>

Here are some benchmark results for this optimisation in jsonyx (let me know if you want to test more cases):

decode	json	jsonyx	fastsimdjson	msgspec	orjson	fastest time
0.0	2.64x	2.09x	1.14x	1.27x	1.00x	37.06 ns
1e-05	2.82x	2.31x	1.08x	1.21x	1.00x	39.16 ns
5e-324	9.29x	8.82x	1.00x	124.77x 1	1.08x	45.95 ns
2e-324	13.54x	13.03x	1.00x	151.55x 1	1.08x	45.02 ns
1.7976931348623157e+308	8.32x	8.14x	1.00x	183.23x 1	1.32x	54.56 ns
1.7976931348623159e+308	1.03x	1.00x	1.03x 2	DNF 3	DNF 3	675.87 ns
0	5.50x	2.95x	1.30x	1.78x	1.00x	11.53 ns
-0	4.36x	2.42x	1.00x	1.36x	1.11x	15.26 ns
4294967296	2.48x	1.47x	1.00x	1.14x	1.07x	47.99 ns
-4294967296	2.56x	1.54x	1.00x	1.23x	1.10x	47.58 ns
18446744073709551616	2.30x	1.79x	1.69x	2.00x	1.00x 4	70.20 ns
-18446744073709551616	2.24x	1.75x	1.60x	1.93x	1.00x 4	73.51 ns

see https://github.com/msgspec/msgspec/issues/1232 ↩ ↩2 ↩3
overflow, reparsed with json ↩
overflow ↩ ↩2
converted to a float ↩ ↩2

bedevere-app Bot added the awaiting review label May 30, 2026

bedevere-app Bot mentioned this pull request May 30, 2026

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

Open

blurb-it Bot and others added 4 commits May 30, 2026 21:22

📜🤖 Added by blurb_it.

b001f96

gh-XXXXX: Add tests for json.loads number parsing edge cases

17d1971

Merge remote-tracking branch 'origin/main' into json-loads-opt

43f14d2

Merge remote-tracking branch 'pte/json-loads-opt' into json-loads-opt

b0c486f

gaborbernat mentioned this pull request Jun 3, 2026

Speed up JSON string decoding for documents with long string values #150871

Closed

eendebakpt mentioned this pull request Jun 5, 2026

gh-150942: Speed up json.loads array and object decoding #150945

Merged

markshannon reviewed Jun 11, 2026

View reviewed changes

eendebakpt added 4 commits June 11, 2026 20:44

review comments

397f3e4

Merge branch 'main' into json-loads-opt

a1b47fe

pep7

57b4dc0

Merge branch 'main' into json-loads-opt

22f1cbf

eendebakpt commented Jun 15, 2026

View reviewed changes

Comment thread Modules/_json.c Outdated

Apply suggestion from @eendebakpt

b5f5fc0

eendebakpt requested a review from markshannon July 10, 2026 18:56

kumaraditya303 reviewed Jul 11, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into json-loads-opt

d3cc3a7

# Conflicts: # Lib/test/test_json/test_decode.py

eendebakpt force-pushed the json-loads-opt branch from 8cd76f1 to d3cc3a7 Compare August 5, 2026 09:20

eendebakpt added 2 commits August 5, 2026 12:03

Merge branch 'json-loads-opt' into HEAD

45fac46

pep7

c14d806

eendebakpt requested a review from kumaraditya303 August 12, 2026 13:54

kumaraditya303 approved these changes Aug 21, 2026

View reviewed changes

bedevere-app Bot added awaiting merge and removed awaiting review labels Aug 21, 2026

eendebakpt mentioned this pull request Sep 3, 2026

gh-155742: Optimize json float parsing #156897

Closed

sprajs reviewed Sep 19, 2026

View reviewed changes

eendebakpt and others added 2 commits September 19, 2026 19:56

Use PyMem_Malloc() instead of a temporary bytes object for long numbers

f84dec8

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Merge branch 'main' into json-loads-opt

6ec3ecd

nineteendo mentioned this pull request Oct 18, 2026

Improve performance of jsonyx.loads for numeric data nineteendo/jsonyx#88

Closed

Use signed accumulation for negative integers in the fast path

ac137b7

Avoids the PyNumber_Negative call: a negative literal of at most 19 characters has at most 18 digits, which always fits in a long long. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

bedevere-app Bot added the type-feature A feature request or enhancement label Oct 19, 2026

Merge branch 'main' into json-loads-opt

fb4cd67

+                          *next_idx_ptr = idx;
+                          rval = PyLong_FromUnsignedLongLong(value);
+                          if (neg && rval != NULL) {
+                              Py_SETREF(rval, PyNumber_Negative(rval));

gh-150638: Improve performance of json.loads and json.load for numeric data by eendebakpt · Pull Request #150639 · python/cpython · GitHub

Repository navigation

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

gh-150638: Improve performance of json.loads and json.load for numeric data#150639
eendebakpt wants to merge 17 commits into
python:mainfrom
eendebakpt:json-loads-opt

eendebakpt commented May 30, 2026 •
edited
Loading

Uh oh!

Uh oh!

markshannon left a comment

Uh oh!

markshannon Jun 11, 2026

Uh oh!

Uh oh!

kumaraditya303 Jul 11, 2026

Uh oh!

eendebakpt Jul 12, 2026

Uh oh!

nineteendo Oct 19, 2026

Uh oh!

eendebakpt Oct 19, 2026

Uh oh!

sprajs left a comment

Uh oh!

eendebakpt commented Oct 19, 2026

Uh oh!

nineteendo commented Oct 19, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

+                      }
                       else
                           rval = PyLong_FromString(buf, NULL, 10);
+                      Py_XDECREF(numstr);

gh-150638: Improve performance of json.loads and json.load for numeric data by eendebakpt · Pull Request #150639 · python/cpython · GitHub

Repository navigation

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

gh-150638: Improve performance of json.loads and json.load for numeric data#150639eendebakpt wants to merge 17 commits intopython:mainpython/cpython:mainfrom eendebakpt:json-loads-opteendebakpt/cpython:json-loads-optCopy head branch name to clipboard

Conversation

eendebakpt commented May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

markshannon left a comment

Choose a reason for hiding this comment

Uh oh!

markshannon Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kumaraditya303 Jul 11, 2026

Choose a reason for hiding this comment

Uh oh!

eendebakpt Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

nineteendo Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

eendebakpt Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

sprajs left a comment

Choose a reason for hiding this comment

Uh oh!

eendebakpt commented Oct 19, 2026

Uh oh!

nineteendo commented Oct 19, 2026

Footnotes

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

gh-150638: Improve performance of json.loads and json.load for numeric data#150639
eendebakpt wants to merge 17 commits into
python:mainfrom
eendebakpt:json-loads-opt

eendebakpt commented May 30, 2026 •
edited
Loading