devashishdxt / desse Goto Github PK

View Code? Open in Web Editor NEW

105.0 4.0 8.0 111 KB

Ultra fast binary serialization and deserialization for types with a constant size (known at compile time).

License: Apache License 2.0

Rust 100.00%

rust binary serialization no-std

desse's People

Contributors

Stargazers

Watchers

Forkers

isgasho cih-y2k icodein gcxfd drtobe embedded-rust-iml lotdeef mayhemheroes

desse's Issues

Add benchmark results in README.md

Desse impl for char is unsound

Consider this function: https://github.com/devashishdxt/desse/blob/master/desse/src/desse.rs#L266
If I will pass incorect Unicode value, it will trigger UB. However, it mustn't because it is not declared as unsafe.

AFAIC this can only be fixed by introducing new trait fn, deserialize_from_unchecked

desse = "0.2.1" : no `DesseStatic` in the root

see image above

API design for serialization and deserialization of dynamically allocated types

Description

API design for Version Tolerant Serialization

Inspirations:

`Desse::deserialize_from()` should return a `Result`

There are many scenarios where deserialization of an object can fail. One such scenario is mentioned here. To handle these usecases and to make it easy for users of this crate to handle errors, Desse::deserialize_from() should return Result. In future, we can also consider returning Result from Desse::serialize() and Desse::serialize_into().

Add documentation for using Desse with enums

Support for enums with unit variants

Benchmark bincode serialization using serialize_into

This is more directly comparable against desse because this way both libraries avoid memory allocation by writing into an existing buffer.

    .with_function("bincode::serialize", |b| {
        let mut buffer = Vec::new();
        b.iter(|| {
            buffer.clear();
            let my_struct: MySerdeStruct = MySerdeStruct { a: 253, b: 64016 };
            black_box(serialize_into(&mut buffer, black_box(&my_struct)));
        })
    }),

Support Option<T: DesseStatic + DesseSize>

This would be pretty handy.

Optional Default types instead of zero-initialized data?

This is not a bug report in a traditional sense, but I was curious to find out more about desse.

I noticed that desse currently uses std::mem::zeroed(), which is being deprecated in favour for mem::MaybeUninit::zeroed. Would it make sense to (optionally) leverage the Default trait if a type implements it? This would be safe code. Or does this cause too much performance overhead (if you happen to have run experiments along those lines)?

Thank you for your time!