ecal icon indicating copy to clipboard operation
ecal copied to clipboard

Possible Enhancement on Serialize()

Open chengguizi opened this issue 2 years ago • 1 comments

I am in the process trying to understand what is happening under the hood for send(). It leads me to the implementation here:

https://github.com/eclipse-ecal/ecal/blob/f12ad8286934b27f96237caccd6371c842ec311c/ecal/core/include/ecal/msg/publisher.h#L138-L141

It is straight forward to understand:

  • It takes the message object (cant be a flatbuffer or capnproto object) and call the Serialize() function to write serialised version of the message into m_buffer
  • Then it calls eCAL::CPublisher::Send(), to actually copy the content of m_buffer into its internally managed memory, which can be SHM.

Regarding the Seialize() implementation for CapnProto, I observed excessive copying of data:

https://github.com/eclipse-ecal/ecal/blob/f12ad8286934b27f96237caccd6371c842ec311c/ecal/core/include/ecal/msg/capnproto/publisher.h#L145-L151

  • It is first serialised into bytes object, then memcpy into m_buffer, before eCAL::CPublisher::Send()

Similiar behaviour is seen in Flatbuffer version:

https://github.com/eclipse-ecal/ecal/blob/f12ad8286934b27f96237caccd6371c842ec311c/ecal/core/include/ecal/msg/flatbuffers/publisher.h#L133-L137

  • flatbuffer's internal byte array is copied into m_buffer, before eCAL::CPublisher::Send()

Possible Improvement:

Can we do without the intermediate m_buffer? I would imagine Seialize() could still keep its internal buffer, and

return(CPublisher::Send(&m_buffer[0], size, time_));

would change to something like

return(CPublisher::Send(getBufferRef(), getBufferSize(), time_));

We could save one memory copy of serialised data in that way.

Side Note: CapnProto seems to provide a way to directly serialise into a target buffer, reference here.

chengguizi avatar Sep 20 '22 17:09 chengguizi

Hi @chengguizi ,

first of all, thanks for your interest in eCAL.

While eCAL is able to handle CapnProto and Flatbuffers, they have never been used "in the field", as internally, we almost only use eCAL in conjunction with Protobuf (but this very extensively). So any optimizations how we can avoid unneccesary copies for CapnProto / Flatbuffers is highly appreciated.

If you're willing to make a PR, we're more than happy to take a look.

KerstinKeller avatar Sep 21 '22 07:09 KerstinKeller