-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
The serialization code generated by asn1scc during OG3 was unexpectedly slow. Just to make sure something was not wrong in our setup we benchmarked it versus other serializers:
| yas: 6.0.2 | 17416 | 11889 | 100.00% |
|---|---|---|---|
| capnproto: 0.6.1 | 17768 | 12354 | 103.91% |
| flatbuffers : 1.7.1 | 17632 | 24788 | 208.50% |
| cereal: 1.2.1 | 17416 | 49126 | 413.21% |
| boost: 1.66.0 | 17470 | 57950 | 487.43% |
| thrift-binary: 0.10.0 | 17017 | 75632 | 636.15% |
| yas-compact: version = 6.0.2 | 13321 | 79722 | 670.55% |
| protobuf: 3.1.0 | 16116 | 89771 | 755.08% |
| msgpack: 2.1.3 | 13402 | 125708 | 1057.35% |
| thrift-compact: 0.10.0 | 13378 | 128549 | 1081.24% |
| avro: 1.8.2 | 16384 | 160471 | 1349.74% |
| ASN.1: 4.1.0.1f | 16716 | 496770 | 4178.40% |
| size | milliseconds | % with fastest |
|---|
The code is available here:
https://gitlab.com/h2020src/og7/cpp-serializers
This test did not include large datasets.
Struct {
int64[1000]
char[100][86]
}
Can OER encoding be triggered somehow instead of uPER (which is not as compact as it should be (specially compared to other solutions) )?
Metadata
Metadata
Assignees
Labels
No labels