Time taking in copying the data on loned pointer

[SomnathHolkar]

We are measuring the performnace for iceoryx. we observed that after taking the pointer of user paylod by calling loan api and writing 2048KB of data into its taking almost 25359 microseconds, but I checked normal copy operation with 2048KB its takin only 160 microseconds.

Please find the iceoryx example code snippet.

` std::unique_ptriox::popo::UntypedPublisher publisher_;
auto serviceString
= iox::cxx::string<20>(iox::cxx::TruncateToCapacity, iox::cxx::convert::toString(0x3));
auto instanceString
= iox::cxx::string<20>(iox::cxx::TruncateToCapacity, iox::cxx::convert::toString(3));
auto eventString
= iox::cxx::string<20>(iox::cxx::TruncateToCapacity, iox::cxx::convert::toString(0x8003));

publisher_ = std::make_unique<iox::popo::UntypedPublisher>(
    iox::capro::ServiceDescription(serviceString, instanceString, eventString));
publisher_->offer(); 

   publisher_->loan(sizeof(ByteVectorIce), alignof(ByteVectorIce))
      .and_then([&](auto& userPayload) {
          //! [loan was successful]
          iox::cxx::vector<std::uint8_t, 4194464> vect;
          vect.resize(2097152);
          auto data = static_cast<ByteVectorIce*>(userPayload);
          auto start_iceoryx = std::chrono::high_resolution_clock::now();
          *data = vect;
          auto elapsed_iceoryx = std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::high_resolution_clock::now() - start_iceoryx);
          auto nanoseconds = static_cast<uint64_t>(elapsed_iceoryx.count());
          auto nanoseconds_1 = iox::units::Duration::fromNanoseconds(nanoseconds);
          auto microseconds = static_cast<double>(nanoseconds_1.toNanoseconds()) / 1000.0;
          std::cout << "ICEORYX Copy time = " << microseconds << " for payload = 2097152" << std::endl;
          publisher_->publish(userPayload);
          //! [loan was successful]
      })
      .or_else([&](auto& error) {
          //! [loan failed]
          std::cout << " could not loan chunk! Error code: " << static_cast<uint64_t>(error)
                    << std::endl;
          //! [loan failed]
      });

`

[budrus]

@SomnathHolkar

I think the slow operation is the copy assignment operator for the cxx::vector with millions of elements. Doing a memcpy(userPayload, static_cast<void*>(&vect), sizeof(ByteVectorIce)); into the chunk is less than 1ms on my machine. Doing an assignment like you do takes also approx 25 ms.

Best is to directly write your data into the memory chunk when creating it. If this is not possible you should at least go for a memcpy

[elBoberido]

Maybe we need to improve the copy/move ctor/assignment operators for our container. If the type is trivially copyable we could just do a memcpy instead of calling the respective ctors/operators. @elfenpiff what do you think?

cc @budrus @MatthiasKillat

[elfenpiff]

@budrus @elBoberido @SomnathHolkar

In my opinion this algorithm above contains an unnecessary and very expensive copy in the line *data = vect;
If one uses the copy assignment the vector iterates over all 2097152 elements and calls 2097152 uint8_t copy constructors which is much more inefficient than memcpy.

Strongly Recommended
*data = vect; can be improved by either letting some kind of function fill the memory. One could for instance write something like void fillData(cxx::vector<uint8_t, 4194464> & v) and call it with data like fillData(*data).

I would NOT recommend a direct memcopy like:

memcpy(data, &vect, sizeof(vect));`

Our containers are trivially copyable but as far as I can see we did not document this in the API and strictly speaking we implemented copy/move operations which would mean that they are technically not trivially copyable - we only exploit an implementation detail here. And this can go very wrong when the type inside the vector is not trivially copyable!
If you stick to uint8_t you can implement it like this but this is dangerous.

Safe memcopy approach

data->resize(vect.size());
memcpy(data->data(), vect.data(), data->size());

The .data() method provides you access to the underlying consecutive memory of the vector and when you copy it via memcpy you essentially copy the content of the vector. It should be slower than the direct memcopy approach but faster than the copy assignment and a lot safer!

Best solution when one requires a copy
I think the most efficient solution would be some raw memory container which has a defined size at compile/runtime and can be assigned some other raw memory which then uses memcopy in the implementation.

[elBoberido]

@elfenpiff what I meant was to to just let the container do a memcpy if std::std::is_trivially_copyable<T>::value is true.

[elfenpiff]

@elBoberido I know. We could also implement something similar for resize with memset when the type is trivially constructible.