Why should I use zserio?

[leland17]

in which case should use the zerio in my work, now the support of the protobuffer are well known and high performance.

[leland17]

i have seen many similarity with protobuffer, but never see the differences.
and your benchmark is not convicing by such a simple example. please tell me in which case should I use this tools.

[fklebert]

I agree that the used benchmark example does not really show the difference.
The main difference is the data size of the encoded stream. In contrast to protobuf, zserio offers the ability to define structures on the bit level.
Simple example: You have a field that shall encode an enum with values NORTH, SOUTH, EAST, WEST.
In proto that will end up using minimum 8 bit + wireformat overhead.
In zserio that can be encoded using 2 bits without any wireformat overhead.

So if you have many fields in a structure with smaller values, then zserio outperforms proto by a margin when dealing with big data amounts. Just think of the example above for a data structure that contains such an enum in a list with 1,000,000 entries or more.

Especially when you are dealing with devices on the edge of the network, where e.g. the data has to be streamed over a mobile carrier network, then data size still matters and will matter even more in the future.
In a nutshell: When you have to work with IoT devices on the edge of the network, consider looking into zserio. If you deal with server farm messaging within the same data center or region, go with proto.

Another plus for zserio is that you can simply retrofit it onto binary data schemas that have not yet been described by a schema IDL, because it does not use any extra bits in the stream (what we refer to as the wireformat of protobuf). So if you have some legacy binary encoding, chances will be quite high that you can write a zserio schema for it, so that you do not need to write parser code for other language for example.

[mikir]

It might be that for some use cases the extra zserio language features which do not have any alternatives in protobuf will play some role. Examples:

• Templates
• Offsets
• Indexed Offsets
• SQLite Extension

[leland17]

I agree that the used benchmark example does not really show the difference. The main difference is the data size of the encoded stream. In contrast to protobuf, zserio offers the ability to define structures on the bit level. Simple example: You have a field that shall encode an enum with values NORTH, SOUTH, EAST, WEST. In proto that will end up using minimum 8 bit + wireformat overhead. In zserio that can be encoded using 2 bits without any wireformat overhead.

So if you have many fields in a structure with smaller values, then zserio outperforms proto by a margin when dealing with big data amounts. Just think of the example above for a data structure that contains such an enum in a list with 1,000,000 entries or more.

Especially when you are dealing with devices on the edge of the network, where e.g. the data has to be streamed over a mobile carrier network, then data size still matters and will matter even more in the future. In a nutshell: When you have to work with IoT devices on the edge of the network, consider looking into zserio. If you deal with server farm messaging within the same data center or region, go with proto.

Another plus for zserio is that you can simply retrofit it onto binary data schemas that have not yet been described by a schema IDL, because it does not use any extra bits in the stream (what we refer to as the wireformat of protobuf). So if you have some legacy binary encoding, chances will be quite high that you can write a zserio schema for it, so that you do not need to write parser code for other language for example.

thanks for your reply.