search

ESROCOS / ESROCOS_Issue_Tracking

Central point to report and track any ESROCOS issues.
0 stars 0 forks source link

ANS.1 speed issues #3

Open xsmarty opened 5 years ago

xsmarty commented 5 years ago

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) )?

mmunoz-gmv commented 5 years ago

No, the supported encodings are uPER and ACN. Is your concern encoding time or compactness? They may be contradictory. Note that in a TASTE interface you can select "native" encoding so that the data is transferred in native representation, without encoding delay. The requisite is that the two functions are deployed on systems with the same binary representation (mainly endianness).