Possible switch from Protobuf to Google Flatbuffer to improve performance

[stefancyliax]

Hello everybody,

the OSI project is currently evaluation a potential switch from Google Protobuf to Google Flatbuffers. This would mean an non-backwards compatible change and warrant a new major release. The project needs to make an informed decision on this major change.

To kick off the evaluation ASAM and the OSI CCB has commissioned Persival GmbH with an investigation in application and performance. Find the reports below:

Application of Google Flatbuffers:
Report_OSI_Flatbuffers_Application.pdf
Performance evaluation with all computation time and data size numbers:
Report_OSI_Flatbuffers_Performance.pdf

Besides, please check the following link collection to the different branches and repos with FMUs, which have been created during this project and can be used for further Flatbuffers testing:

• OSI Performance Evaluation scripts:
  https://gitlab.com/persival-open-source/open-simulation-interface/osi-performance-evaluation
• DummySource/DummySensor as Flatbuffers:
  o Branch for OSMP DummySource and DummySensor as Flatbuffers (with _flat):
  https://github.com/OpenSimulationInterface/osi-sensor-model-packaging/tree/feature/flatbuffers_examples/examples
  o Branch for OSMP DummySource and DummySensor as Flatbuffers version with the Object API (with _flat):
  https://github.com/OpenSimulationInterface/osi-sensor-model-packaging/tree/flatbuffers_object_api/examples
• Reflection-based lidar model (Reflections->Detections) as Flatbuffers version:
  https://gitlab.com/tuda-fzd/perception-sensor-modeling/reflection-based-lidar-object-model/-/tree/flatbuffers
• OSI Trace File Player to feed e.g. the reflection based lidar model:
  o Hints on .osi Trace Files:
  https://opensimulationinterface.github.io/osi-documentation/#_osi_trace_files
  o OSI Trace File Player:
  https://gitlab.com/persival-open-source/open-simulation-interface/osi-trace-file-player
  o OSI Trace File Player as Flatbuffers version:
  https://gitlab.com/persival-open-source/open-simulation-interface/osi-trace-file-player-flat

NOTE: We use OpenMCx as a co-simulation tool to connect source/player and sensor model respectively: https://gitlab.com/persival-open-source/open-simulation-interface/osi-performance-evaluation#set-up-a-co-simulation
We hope that our READMEs are already meaningful enough to use everything, but of course we are available for your questions.

But now it’s your turn to implement on this basis and give further feedback to the project if the switch to flatbuffers is an improvement in your implementation of OSI.

[globberwops]

One aspect I find quite important is the support of the future OSI serialization format by other middlewares.
Eclipse eCAL claims to support protobuf/flatbuffers/capnproto: https://projects.eclipse.org/projects/automotive.ecal
gRPC supports protobuf/flatbuffers as well: https://google.github.io/flatbuffers/flatbuffers_grpc_guide_use_cpp.html

Are there any other middlewares that should be taken into account in this decision?

Martin Stump martin.stump@mercedes-benz.com on behalf of MBition GmbH, Provider Information