[zeromq-dev] idea for perf enhancement in user code

Andrew Hume andrew at research.att.com
Wed Dec 14 03:54:51 CET 2011


this seems like an unusual case to force a library change.

On Dec 13, 2011, at 7:33 PM, Chuck Remes wrote:

> I have a protocol (like majordomo) that uses message parts to send some of the same "boilerplate" data on every message. Currently I allocate a new zmq_msg_t for each of these "frames" and let the library handle the deallocation, but it occurred to me that this might not be a good idea.
> 
> What if I allocate the zmq_msg_t once and, before passing it to zmq_send/zmq_sendmsg, I call zmq_msg_copy on it to increase its refcount. The library returns another zmq_msg_t to me in the buffer I gave it but it let's me avoid the memcpy call for the "data" (which may be a negligible cost for small data but could be significant for large buffers). 
> 
> Now that I have typed this out, it would be nice if I could operate *directly* on the original zmq_msg_t and avoid the effort of even creating a destination zmq_msg_to for zmq_msg_copy to replace. What about a zmq_msg_increment_refcount(zmq_msg_t *src) api call to let me do this work directly?
> 
> Does anyone see a problem with this approach? I'm going to experiment with it in a project I am working on but I wanted to throw the idea out there just in case someone with a sharper eye can see a flaw.
> 
> cr
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111213/00be1759/attachment.htm>


More information about the zeromq-dev mailing list