Ok. Thank you for this information.
On 08/20/2017 02:51 PM, Luca Boccassi wrote: > On Sun, 2017-08-20 at 14:27 +0200, Nis Meinert wrote: >> Dear all, >> >> I just have started with zmq and have a basic question concerning the >> memory allocation / deallocation: >> >> My program creates objects of some significant amount of bytes, such >> that it turns out be a smoking gun for performance issues. Thus it is >> worth to think twice before doing unnecessary memory allocation and >> copying. >> >> What do you think is best practice: >> >> (1) do not allocate the object on the heap (fast) and copy the object >> via memcpy (slow) in order to use it with zmq_send, or >> >> (2) allocate the object via new on the heap (slow) and use the >> technique >> of zero-copy (http://zeromq.org/blog:zero-copy) by passing a >> respective >> deallocater? >> >> Am I right, that zmq itself does a dynamic memory allocation on the >> heap? In this case this bottleneck is not avoidable and (2) is the >> better choice... >> >> Cheers, >> Nis > If the payload is 33 bytes or greater (warning: this is an internal > implementation detail and subject to change at any time) then the > library will malloc a buffer. That is because the sending is > asynchronous and might complete long after the program stack frame has > gone. > > If you use the zero-copy APIs then the library will take ownership of > your buffer. > > So it sounds like your guess is correct. > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
