[PERF]: swap out json_deserializer for simd_json

[universalmind303]

This swaps out json_deserializer for simd_json. This does show some pretty noticeable performance gains across the board (~10-20%). This is nice as not only does the local reader show improvements, the object store readers should also benefit from this.

some perf tests I ran locally

%%timeit
daft.read_json('./stackexchange_sample.jsonl').collect()

# branch: main
# 64.4 ms ± 1.05 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
# branch: simdjson
# 52.5 ms ± 763 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

%%timeit

# tpch sf 5 'customer' table
daft.read_json('./customer.json').collect()

# branch: main
# 289 ms ± 2.88 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
# branch: simdjson 
# 244 ms ± 5.88 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

---

Edit:

Added support for preserving order
It isnt' quite as performant as the unordered version, but it is still noticeably faster than using json_deserializer

# stack_exchange_sample.jsonl
# 56.9 ms ± 833 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

# tpch sf 5 'customer' table
# 256 ms ± 2.98 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) 

[clarkzinzow]

Left a preliminary review, I'm really liking the cleanup that the simd_json port enables!

Biggest remaining thing to figure out is how to preserve key order in Object values, which is supported in json_deserializer but is not supported in simd_json: simd-lite/simd-json#270

[clarkzinzow]

Nice, I like this a good bit more than the int/float-specific closures!

[clarkzinzow]

For integers and floats that contain exponents, I'm assuming that the string representation of StaticNode::I64 and StaticNode::F64 values won't preserve the exponent format, right? E.g. 1.5e9, when decoded into a string field, will be decoded as "1500000000". Is that correct?

[universalmind303]

Yeah, without manually parsing from simd_json's Tape, there isn't a way to preserve the exponent format.

[clarkzinzow]

I think that change in behavior is fine, we can always special-case that if it ends up being an issue.

[clarkzinzow]

LGTM overall, just a few questions around the unsafe code!

[clarkzinzow]

Nice! I'm happy that this order-preserving extension ended up being pretty thin.

[clarkzinzow]

I'm assuming that the safety contract here for as_bytes_mut(), i.e. that the post-deserialization content of the slice is valid UTF8 before the parsed record is used, is trivially satisfied by the deserializer + records never being used after parsing?

[universalmind303]

yeah exactly. simd_json parser is "destructive" in nature, so as long as you don't attempt to reuse the original data after parsing, this is generally safe

[clarkzinzow]

Safety condition here is that a top-level .parse() will never be called on an empty byte slice - do we know that this can't happen since Deserializer::from_slice() errors on an empty byte slice? The only condition check I found when skimming the Deserializer::from_slice() implementation to suggest that it errors when given an empty slice is this: https://docs.rs/simd-json/latest/src/simd_json/lib.rs.html#1081-1083

[universalmind303]

do we know that this can't happen since Deserializer::from_slice() errors on an empty byte slice?

I would assume the Deserializer catches any errors before it makes it into this wrapper, but I can't say with certainty. They do have a pretty extensive test suite that I would hope catches this. So I think unfortunately we just assume that simd_json does what it's supposed to do.

Anecdotally, polars has been using simd_json::Deserializer for a couple years and has never encountered an out of bounds here.

[clarkzinzow]

I think that change in behavior is fine, we can always special-case that if it ends up being an issue.