Repository navigation
Speed up escaped byte buf parsing - #534
Conversation
1bdb8de to
1769934
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #534 +/- ##
===========================================
- Coverage 100.00% 99.39% -0.61%
===========================================
Files 85 85
Lines 14658 14271 -387
===========================================
- Hits 14658 14184 -474
- Misses 0 87 +87 ☔ View full report in Codecov by Sentry. |
The codecov regression seems unrelated and mostly occurs in derives and test macros - it should be handled separately |
ron has ~450 correctness tests but none that guard the asymptotic cost of parsing. That gap let ron-rs#534 regress escaped_byte_buf from O(n) to O(n^2) across v0.9.0..=v0.12.2 — four releases — with every test green, and a second O(n^2) entered next_bytes_is_float in v0.12.2 (ron-rs#602). tests/complexity_scaling.rs asserts that parse time grows at most linearly: it doubles the input and checks the time ratio (~2 linear vs ~4 quadratic; threshold 3.0), using min-of-N + median to stay robust to timing noise. The tests are #[ignore]d and run in a dedicated release CI job, so they never slow down or flake the normal test job. Two forms guard the regressions fixed in ron-rs#608 (next_bytes_is_float) and ron-rs#610 (escaped_byte_buf); two linear controls keep the harness honest. On the pre-fix tree (d0e99bc) those two forms report ratio ~4.0 and fail the 3.0 threshold; on current master they are ~2.0 and pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The fuzzer times out when parsing a 100k long unicode string because checking for escaped strings is slow. This PR makes two small changes to speed this case up by ~ x3
'"'and'\\'* [ ] I've included my change inCHANGELOG.md