[zeromq-dev] [czmq] zero-copy API Deprecation

[Uli Köhler]

Hi,
I noticed the zero_copy API functions are deprecated in the current git
master, see commit de8c1bc4

In general I agree with the API being simpler without zerocopy versions,
and about adding a znocopy module instead. As noted in the commit log, it's
rather one-less-copy than zero-copy.

However, in my usecase, most frames (especially header frames are constant
data (magic byte, protocol version, response code etc.), the others can't
be zero-copied at all.
I'm not sure if I'm the only one with frequent sending of constant data
frames, but I wrote a quick benchmark to support "Zero"-Copy in this case:
https://gist.github.com/ulikoehler/cf934b0df078c2fc82eb
It creates 1e8 frames and sends them to a pub socket that is expected to
throw them away.

On my Linux x86_64 Laptop (using GCC 4.7.3 and the most recent ZMQ/CZMQ
versions), the copy version takes about 16 seconds, whereas the nocopy (-->
zero_copy) version takes about 12 seconds.
After all, "zero"-copy is about 25% faster for me. To be honest, this looks
pretty significant to me, even if the testcase is idealized.

I'm not sure if there is any significant performance gain for non-constant
data, but given the results, I propose to add functionality to handle
constant data efficiently, if it's a common use case for the community.

Because the workaround using doNothingFree() as zero-copy free fn is
somewhat awkward, unneccessarily slow and requires you to cast-remove the
constness of your pointer as well as adding two redundant argument, the
const-API would be much simpler than zero-copy.

Please tell me your opinion about this!

Best regards,
Uli Köhler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130708/4d9f46eb/attachment.htm>