Blog post: Making Slow Rust Code Fast

[ashishnegi]

@H2CO3

I have yet to see a real-world, non-microbenchmark case where JSON/BSON/whatever (de)serialization is a bottleneck.

Online services serving many concurrent users/requests do spend a lot of time in deserializing user request and serializing response, since data is mostly cached in memory. That is why json is not considered for good communication between internal services. I have seen this in many production services.

[Fredrik]

I like that you added JSON and Message Pack for comparison. Maybe also add CBOR?

@patrickfreed

For deserialization, the difference between bson::from_slice and your implementation is definitely more distinct, though I think that has more to do with the implementation in bson rather than any limitation of serde , given that the msgpack serde library ( rmp_serde ) seems to be able to achieve similar performance.

You can't make such a conclusion when comparing apples to oranges. You have to look into the details.

rmp_serde::to_vec achieves high performance by not serializing field names. You have to use rmp_serde::to_vec_named for a fair comparison.

Also to consider (after the important detail above) is that Message Pack is not BSON.

• Arrays are prefixed with the number of items, so arrays can be allocated upfront with the correct capacity when deserializing.
• Byte lengths of arrays and objects are not encoded, so no need to backtrack when serializing.
• Keys of array elements are not encoded, significantly reducing the number of bytes to serialize and deserialize.

For further performance improvements in deserializing arrays, they could be allocated in a bump arena. This reduces the number of allocations (and deallocations) for any format, but is particularly helpful in making BSON competitive with Message Pack, because arrays could have a preallocated capacity for a pretty large number of items, and any capacity that is left over after the end of one array can be immediately used for the next array.

@patrickfreed

in practice, the extra ~200ns spent in deserialization is dwarfed by the time spent doing other things like network I/O

There's async for that. So what matters depends on what you're measuring.

[univerz]

@Fredrik

You can't make such a conclusion when comparing apples to oranges. You have to look into the details.

rmp_serde::to_vec achieves high performance by not serializing field names. You have to use rmp_serde::to_vec_named for a fair comparison.

thank you for careful read, this mistake is on me. new numbers (EDIT: for older, different benchmark) are less impressive, however there is still ~2.8x difference even for simple struct {i: i64} (and potentially i: ObjectId - this was the main reason for the benchmark as it was an order of magnitude slower).

[univerz]

@H2CO3

@patrickfreed

the extra ~200ns spent in deserialization is dwarfed by the time spent doing other things like network I/O

Exactly. I have yet to see a real-world, non-microbenchmark case where JSON/BSON/whatever (de)serialization is a bottleneck.

bioinformatics is on a heavy side of postprocessing. on my websites & lighter number crunching projects, bson was really visible & resulting perf was worse than (c++,) python & even one old php webpage i rewrote in rust. it's significalntly better now, but numbers in this thread suggest there is still room to do several double digits improvements.