Repository navigation
Decoding subnormal numbers is really slow #1232
Description
Description
I was running benchmarks for different json libaries and noticed that decoding subnormal numbers is 150x slower than orjson (it's even slower than the python implementation of jsonyx which is not shown here):
| decode | json | jsonyx | msgspec | orjson | yyjson | fastest time |
|---|---|---|---|---|---|---|
| 65,536 subnormal floats | 11.27x | 11.63x | 150.63x | 1.00x | 1.12x | 2508.46 μs |
Input data: json.dumps([5e-324] * 65_536).encode().
Full benchmark code: https://github.com/nineteendo/jsonyx/blob/main/bench/__main__.py
Activity
provinzkraut commentedon Oct 6, 2026
Very interesting. Thanks for reporting this!
provinzkraut commentedon Oct 6, 2026
Right, so, we generally fall back onto our slow
parse_number_fallbackparser instead of the fast-path one for everything that's out of range of thems_atof_powers_of_10table (exponent range there isrange(-307, 289)). We could fix this, but then the fast-path parser would also need to handle subnormals and overflows, which it currently does not.It's not too much of an effort (probably) to do this, but I'm unsure whether it's worth it that way. Even with that fix in, there's still other pathological cases (e.g. floats with more than 19 significant digits right on a rounding boundary are an order of magnitude slower than
orjson). Maybe we should investigate howyyjson(which is whatorsonuses under the hood) does here, and take some inspiration from it.@sobolevn any opinions?
provinzkraut commentedon Oct 6, 2026
Seems that
yyjsonhas an additional fast-path attempt added at the point where we give up and resort to the exact parser: https://github.com/ibireme/yyjson/blob/6447536015f3d600f3d65323b10976103b337ca7/src/yyjson.c#L4317-L4341. It seems to be lifted from https://github.com/google/double-conversion. We could probably adopt this.sobolevn commentedon Oct 6, 2026
I would say that copying
orjsonway of doing this would probably be the best bet :)Unless we know how to make this even faster.
provinzkraut commentedon Oct 6, 2026
Well,
yyjson, as that's where it's implemented.I think we might. If we add the additional 2 fast-paths on top of what we have right now, and speed up our fallback path (something
yyjsondoes, where they don't go straight into the exact decode routine), we could end up faster thanorjsonin the standard and pathological cases. In theory at least.nineteendo commentedon Nov 1, 2026
Note that the same slowdown exists for very large floats:
5e-3242e-3241.7976931348623157e+308Should this get its own issue? Right now I just linked to this one.
sobolevn commentedon Nov 1, 2026
I think that we should consider using https://github.com/kolemannix/ffc.h instead of our own implementation :)
perf: speed up subnormal float parsing (msgspec#1237)