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
Hi, 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
