ecal
ecal copied to clipboard
Possible Enhancement on Serialize()
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 intom_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 intom_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.
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.