Repository navigation
Performance between 'Values API' and 'Serde Compatible API'. #370
Description
I noticed that simd-json offers two main entry points for usage: 'Values API' and 'Serde Compatible API'.
I ran benches/parse.rs to test the performance. I added code below to test simd_json::serde::from_slice:
fn simd_from_slice(data: &mut [u8]) {
let _: serde_json::Value = simd_json::serde::from_slice(data).unwrap();
}
group.bench_with_input("simd_json::serde::from_slice", &vec, |b, data| {
b.iter_batched(
|| data.clone(),
|mut bytes| simd_from_slice(&mut bytes),
BatchSize::SmallInput,
)
});Here's the result:
| Throughput(MiB/s) | simd_json:: to_borrowed_value | simd_json:: to_borrowed_value_with_buffers | simd_json:: to_owned_value | simd_json:: serde::from_slice | serde_json:: from_slice |
|---|---|---|---|---|---|
| apache_builds | 378.61 | 323.86 | 170.99 | 164.81 | 140.08 |
| event_stacktrace_10kb | 983.51 | 1070.9 | 762.83 | 709.25 | 501.10 |
| github_events | 455.06 | 442.80 | 226.45 | 178.68 | 141.91 |
| canada | 142.38 | 164.17 | 146.48 | 114.10 | 152.69 |
| citm_catalog | 312.69 | 340.59 | 234.10 | 237.55 | 225.40 |
| log | 403.55 | 467.40 | 196.92 | 155.88 | 119.01 |
| 367.24 | 372.41 | 207.64 | 156.72 | 120.17 |
The 'Values API' is mostly better than serde except canada(146.48 vs 152.69). However, the performance of 'Serde Compatible API' seems not that good, the result of canada cannot be acceptable(114.10 vs 152.69). I'd like to use simdjson to increase the performance, so it's better to use 'Values API'? And if my data is similar to canada, it's better not to use simdjson?
Activity
Licenser commentedon Feb 29, 2024
Hi,
sorry for the late reply I'm just finishing some vacationing and was mostly away from the computer.
That makes a good bit of sense, the serde mapping code is quite complex and by that expensive to execute - irespective of the decoder (serde-json, simd-json, serde-yaml ... etc).
By contrast the value API is kept as simple as possible so the overhead is just lower. In some cases the extra cost of allowing abritary values is less then the extra cost of serde.
There is a 3rd api, the simd-json-derive api that allows to decide directly into structs w/o the value API, that will be faster still but is less flexible.
Last but not least, I want to point out that this isn't serde being bad, or not well written. serde is made to allow nearly arbritary format translations and is extremely powerful that way - it does this extremely well, but such power usually comes at a cost. the simd-json-derive macros are extremly specific so can take a lot of shortcuts serde simply can't that's where the performance benefit can be gained.
PSeitz commentedon May 21, 2024
I implemented the
ValueBuildertrait forserde_json_borrow::Value.In this bench it is slightly slower than the simd_json
serdevariant in most benches.I think it should slightly faster than
BorrowedValue, as the datastructures are simpler. I didn't profile, but could be related to missing inlines, as this is cross-crates.There's also a dependency to
halfbrown::Hashmapon thesimd_json::value::deserializeAPI. It would be good to reexport or switch to something more generic like an Iterator.The branch is here https://github.com/PSeitz/serde_json_borrow/tree/simd_json_value_builder.
Licenser commentedon May 21, 2024
This is really awesome @PSeitz !