erickt / erickt/rust-serialization-benchmarks

Add some clarity to interpreting the results

Open
#9 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
93
Forks
15
PR merge metrics
No merged PRs in 30d

Description

I was curious what was causing the outlier results, especially this one:

```
test goser::capnp::bench_serialize ... bench: 32 ns/iter (+/- 19) = 14000 MB/s
```

Then I came across this:

> These benchmarks measure the cost of translating between in-memory and on-wire representations of data. For Cap'n Proto, the two representations are exactly the same, so the translation is either a no-op or a memcpy. - [Source](https://www.reddit.com/r/rust/comments/2lzc9n/rust_serialization_part_21_now_with_more/clzm4y9/)

The README for this project should probably point that out? I see [one of your old articles about the project](http://erickt.github.io/blog/2014/11/03/performance/) provides details, in particular one explaining cap'n'proto:

> Cap’n Proto doesn’t really do serialization, but lays the serialized data out just like it is in memory so it has nearly zero serialization speed.

A link to the article might be helpful? The README here mentions it's a JSON serialization benchmark, but as that quote points out, the results for Cap'n'Proto aren't really representative of such.

---

I am a little confused regarding the [zero-copy deserialize support with Serde and MessagePack](https://users.rust-lang.org/t/rust-messagepack-and-serde-1-0/10524). If I understand, that would be implemented similar to the deserialize benchmark but can drop a line in the closure like so?:

```Rust
let _log: Log = ::rmp_serde::from_slice(&*buf).unwrap();
```

This only seems to provide a small ~10% improvement for me, nothing like what cap'n'proto is showing for it's deserialize, is that a different kind of zero-copy?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.