pydantic/jiter - CodSpeed

jiter

Blog Docs Changelog

Performance History

Latest Results

main

4 hours ago

Replace the x100 Python benchmarks with a thousand long strings (#296) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

main

5 hours ago

Replace the x100 Python benchmarks with a thousand long strings python_parse_x100 and its uncached twin do identical work, since a 100-character string is over the cache's 64-byte limit either way, yet they measured 164 ns and 152 ns in the same CodSpeed run and have flipped between 128 and 164 ns on commits that don't touch string parsing. At 130 ns the benchmark is measuring where pymalloc placed one string object, not the parser. Keep the path they covered, uncached creation of strings too long for the cache, but over 1000 ASCII strings of 64 to 2000 characters so placement effects average out over a thousand allocations and the work per iteration is ~100 µs. The input is generated from a fixed seed so nothing is checked in. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qm4KCoN9xWsA4HRCL3Lx63

long-strings-bench

5 hours ago

Reserve the decode tape once per escaped string (#295) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

main

5 hours ago

Document MAX_TAPE_RESERVE Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qm4KCoN9xWsA4HRCL3Lx63

reserve-tape-once

6 hours ago

Reserve the decode tape once per escaped string Decoding a string with escapes appends to the tape chunk by chunk, so a fresh parser's tape grew through four reallocs for a few-hundred-byte string. Under glibc that is 36-42% of the unicode_jiter_iter benchmark (see its CodSpeed flamegraph), and whether those reallocs move the buffer depends on the heap state, which is why the benchmark flips 15% between commits that don't touch this code at all. The decoded string is never longer than the raw one, so the remaining input bounds the tape; reserve that, capped at 8 KB so a short string at the start of a large document doesn't reserve the document. x86_64 glibc (codespace), criterion: sentence_jiter_iter 256 ns -> 125 ns unicode_jiter_iter 317 ns -> 165 ns arm64 macOS: sentence_jiter_iter 231 ns -> 124 ns unicode_jiter_iter 268 ns -> 157 ns The value benchmarks and everything without escapes are unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qm4KCoN9xWsA4HRCL3Lx63

reserve-tape-once

6 hours ago

release: 0.17.0 (#294) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

main

7 hours ago

release: 0.17.0 (#294) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

main

7 hours ago

Latest Branches

-8%

Replace the x100 Python benchmarks with a thousand long strings#296

6 hours ago

fd42ac0

long-strings-bench

×2.2

Reserve the decode tape once per escaped string#295

6 hours ago

7edb809

reserve-tape-once

-7%

release: 0.17.0#294

7 hours ago

6782b5d

release-0.17.0

© 2026 CodSpeed Technology

Home Terms Privacy Docs