Move bitcode to full benchmark from extra
Closed this issue · 2 comments
I noticed bitcode was in the extra benchmark category instead of full. As far as I could tell this was due to it lacking u128 and CString, so I added support for them to bitcode. Hopefully this is enough for bitcode to be part of full, but if it's missing anything else please let me know.
P.S. bitcode would benefit from using a buffer in deserialize/decode because it copies the [u8] to a [u64] internally.
I think that should be enough. I'll move it. Thank you!
Regarding buffer for deserialize / decode: Binary serialization to me somewhat implies that an array of bytes is somehow used as transport, so opportunities for buffer to buffer transcodes seems like they should be rare? In theory you could device a mechanism for directly using u64's for transports - assuming it communicates and deals with endianness issues, at which point I'd be more inclined to test it like that. Maybe you already have it?
In theory you could device a mechanism for directly using u64's for transports - assuming it communicates and deals with endianness issues, at which point I'd be more inclined to test it like that. Maybe you already have it?
We decided to output [u8] instead of [u64] because most existing libraries use [u8] and we didn't want to force everyone to do their own conversion. Also a [u64] would potentially have 7 extra padding bytes compared to a [u8]. Additionally we want to be able to change the internal serialization code in the future without exposing the changes to the user.
The bitcode::Buffer::decode/bitcode::Buffer::deserialize apis allow multiple decode/deserialize calls to reuse allocations. Converting the input [u8] to a Vec<u64> isn't the only allocation reused by the buffer. Strings are deserialized into a scratch buffer and then copied (for ArrayString) or allocated and copied (for String).