Allow people to use bigarrays instead of string
UnixJunkie opened this issue · 10 comments
Hi,
It would be nice if the send and receive functions could use a bigarray instead of a string.
That would allow less data copying.
The new send would then take a bigarray, an int offset and an int length as parameters.
Receive would take a bigarray, an int offset and a max length as parameters.
We would welcome such a patch if it came with a reasonable benchmark. My hunch is that memcpy is a quite cheap operation that could easily be cheaper than the overhead of bigarray allocations if the application cannot recycle the bigarrays sufficiently.
I guess the bigarray would be your buffer: you just allocate it once then keep reusing it.
Maybe you can label this issue as a feature request.
I probably won't have time to work on it.
If it happens, I can benchmark it.
Yes, I'm sure there will be a performance improvement in that case. But if the application just forwards messages from one ZMQ socket to another then consider using ZMQ.Proxy.create. It'll be much faster since it happens purely in C code. We use the Proxy feature ourselves for a service that receives messages on one socket and copies each message to two other sockets (using the capture argument to create).
I have a WIP branch which adds some low(er) level msg handling functions which would allow some closer-to-zero-copy message handling. I've been working on it in my spare time so it may take a bit longer to polish up. If there's still interest I can spend some more time getting that ready for a proper PR.
@hcarty I don't have a need for this right now.
If it was there when I used zmq, I would probably have given it a try.
Can you still send messages asynchronously with your closer-to-zero-copy version?
Is some buffer management exposed to the user (which is not cool but was in my text-only proposal)?
@UnixJunkie Asynchronous delivery is still possible. The implementation does not require the user to manage the buffer. I have considered exposing an unsafe interface to have more direct control over the buffer but I'm not sure if the benefits are worth the potential segfaults.
Please see my comments on PR #42.