Hi Luca,
thanks for the details. Indeed I understand why the "content_t" needs to be
allocated dynamically: it's just like the control block used by STL's
std::shared_ptr<>.
And you're right: I'm not sure how much gain there is in removing 100% of
malloc operations from my TX path... still I
Another reason for that small struct to be on the heap is so that it
can be shared among all the copies of the message (eg: a pub socket has
N copies of the message on the stack, one for each subscriber). The
struct has an atomic counter in it, so that when all the copies of the
message on the
The second malloc cannot be avoided, but it's tiny and fixed in size at
compile time, so the compiler and glibc will be able to optimize it to
death.
The reason for that is that there's not enough room in the 64 bytes to
store that structure, and increasing the message allocation on the
stack
Hi Stephan, Hi Luca,
thanks for your hints. However I inspected
https://github.com/dasys-lab/capnzero/blob/master/capnzero/src/Publisher.cpp
and
I don't think it's saving from malloc()... see my point 2) below:
Indeed I realized that probably current ZMQ API does not allow me to
achieve the
On 04.07.19 14:29, Luca Boccassi wrote:
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.
Some example can be found here:
https://github.com/dasys-lab/capnzero/tree/master/capnzero/src
The classes Publisher
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%
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%
