tls_codec performance

[franziskuskiefer]

Hey @franziskuskiefer question for you, how is the current encoding / decoding performance? If there are places you think we can help make improvements let us know.

Originally posted by @tomleavy in https://github.com/RustCrypto/formats/issues/250#issuecomment-975838633

That's a good question. Before being able to answer the question we'd need to know what the performance is and understand if its any good. There's a very basic benchmark here thttps://github.com/RustCrypto/formats/blob/4d0c0530be501e00dd1fbc25024db02eeffd669b/tls_codec/benches/tls_vec.rs. I wrote it to look at the performance impact of (de)serialising each element vs using the specialised ByteVec.

• [ ] Write benchmarks for real-world scenarios to measure performance.

There are two things that I think are worth looking at.

• [ ] Memory allocations are the most expensive operation. Are there any unnecessary allocations? Is any buffer resized unnecessarily?
• [ ] The existing benchmarks show that invoking (de)serialise for each element in a vector takes significant amount of time. Can this be optimised somehow?

[OtaK]

I think I found some extraneous allocations in the following code points; Vec::new() allocates an empty vec and each push that goes over the capacity effectively doubles the capacity. Which means that the bigger the vec, the more we allocate needlessly and in the middle of deserialization.

https://github.com/RustCrypto/formats/blob/5729f74dd1bae43bb2cf9a10ba3a42a74f0a7760/tls_codec/src/quic_vec.rs#L113 Replaced by a capacity hint

// Or divide by T::tls_serialized_len() ?
let number_of_elements = length / std::mem::size_of::<T>();
let mut result = Vec::with_capacity(number_of_elements);

Probably the same can be applied here https://github.com/RustCrypto/formats/blob/5729f74dd1bae43bb2cf9a10ba3a42a74f0a7760/tls_codec/src/tls_vec.rs#L70