Create a node API benchmark based on zenoh

[phil-opp]

Adds the simple, unscientific benchmark example used to create the benchmarks reported in #169 (comment).

[phil-opp]

New results:

ZENOH:
Latency:
size 0x0     : 125.854µs
size 0x8     : 125.051µs
size 0x40    : 134.696µs
size 0x200   : 143.422µs
size 0x800   : 140.832µs
size 0x1000  : 143.49µs
size 0x4000  : 131.922µs
size 0xa000  : 121.403µs
size 0x64000 : 400.116µs
Throughput:
size 0x0     : 319920 messages per second
size 0x8     : 439601 messages per second
size 0x40    : 403327 messages per second
size 0x200   : 350658 messages per second
size 0x800   : 55052 messages per second
size 0x1000  : 47572 messages per second
size 0x4000  : 14316 messages per second
size 0xa000  : 7120 messages per second
size 0x64000 : 917 messages per second

ICEORYX:
Latency:
size 0x0     : 79.726µs
size 0x8     : 51.027µs
size 0x40    : 45.64µs
size 0x200   : 63.176µs
size 0x800   : 64.402µs
size 0x1000  : 54.382µs
size 0x4000  : 58.624µs
size 0xa000  : 61.343µs
size 0x64000 : 77.179µs
Throughput:
size 0x0     : 278009 messages per second
size 0x8     : 262613 messages per second
size 0x40    : 223301 messages per second
size 0x200   : 145858 messages per second
size 0x800   : 71805 messages per second
size 0x1000  : 43043 messages per second
size 0x4000  : 13365 messages per second
size 0xa000  : 5279 messages per second
size 0x64000 : 1119 messages per second

[haixuanTao]

So just for your information, for zenoh, the latency is going to be higher if you have multiple receivers of the same message because it's going to have to send those messages multiple times.

Having multiple receivers can happen quite a lot on data such as images or position, etc...

You don't have to include it now, but i feel like this might be more representative of the actual latency within the dataflow.

The rest looks good! Thanks!

[kydos]

These are interesting results. I am a bit surprised by the latency increase for size 0x64000, as the size of packet that is sent on the network does not change, it is just an "address" the data. I would also like to know which version of zenoh have you used to run the tests, as the latest version has some important improvements on latency and that may reduce the gap between zenoh and ICEOryx.

That said, considering the fact that zero-copy is in Zenoh an optimisation while IceOryx has been designed ground-up for that purpose, I think that that looks quite good.

We'll do some investigation to see if we can reproduce the strange increase in size for 0x64000. Will keep you posted.

Don't hesitate to reach us out (on Zenoh's discord https://discordservers.com/server/914168414178779197) if you have questions.

[phil-opp]

@kydos Thanks for taking a look! Please keep in mind that these benchmarks are very basic and not scientific at all. So the higher latency for 0x64000 might not be caused by zenoh at all.

I would also like to know which version of zenoh have you used to run the tests, as the latest version has some important improvements on latency and that may reduce the gap between zenoh and ICEOryx.

We are currently using a pinned dependency on commit eclipse-zenoh/zenoh@79a136e. We tried to update to v0.6.0-beta when it was released, but ran into some deadlock problems. (We saw that you released a v0.7.0-rc version before the holidays and we plan to try it soon.)

Don't hesitate to reach us out (on Zenoh's discord https://discordservers.com/server/914168414178779197) if you have questions.

Thanks a lot!

[haixuanTao]

This can be closed at it has been merged as part of #162.