[zeromq-dev] Memory pool for zmq_msg_t

Luca Boccassi luca.boccassi at gmail.com
Thu Jul 4 14:29:52 CEST 2019

On Thu, 2019-07-04 at 14:21 +0200, Francesco wrote:
> Hi all,
> I'm doing some benchmarking of a library I wrote based on ZMQ.
> In most of my use cases if I do a "perf top" on my application thread
> I see something like this:
>   12,09%  [kernel]              [k] sysret_check
>    7,48%  [kernel]              [k] system_call_after_swapgs
>    5,64%  libc-2.25.so          [.] _int_malloc
>    3,40%  libzmq.so.5.2.1       [.] zmq::socket_base_t::send
>    3,20%  [kernel]              [k] do_sys_poll
> That is, ignoring the calls to Linux kernel, I see that malloc() is
> the most time-consuming operation my software is doing. After some
> investigation that's due to the use I do of zmq_msg_init_size().
> Now I wonder: somebody has ever tried to avoid this kind of malloc()
> by using the zmq_msg_init_data() API instead and some sort of memory
> pool for zmq_msg_t objects?
> I've seen some proposal in this email thread:   
> https://lists.zeromq.org/mailman/private/zeromq-dev/2016-November/031131.html
> but as far as I know nothing was submitted to the zmq community,
> right?
> Thanks,
> Francesco


The zmq_msg_init_data is there for that purpose and it works well - if
you pass your own buffer, it won't allocate new ones internally. Same
on receive since v4.2.0, the buffer returned by the kernel syscall is
used directly in the message.

How users make use of these primitives is up to them though, I don't
think anything special was shared before, as far as I remember.

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20190704/2cefc3e4/attachment.sig>

More information about the zeromq-dev mailing list