Conversation
Fixed a performance problem when receiving large messages of unknown size. Also, changed the recv() inputs to more closely match the zmq API (without breaking any unit tests). The zmq API requires a buffer allocation for the largest anticipated message (if the buffer is too small, then the message will be truncated). The previous implementation of matlab-zmq recv() triggered allocation/deallocation of the largest anticipated buffer during each call from MATLAB, even if the actual message received was trivially small. With the submitted change, the buffer is declared as a static variable and the memory is (re)allocated using realloc. Finally, mexAtExit is used to register a function to free memory on program termination.
|
Hi @dddvision, it seems very good to me. I am still confused with a point, would you mind to clarify it? Is there any special reason to use the standard C |
|
Hi Anderson, According to MATLAB documentation... "mxRealloc registers the allocated memory with the MATLAB memory manager. If the memory is freed when returning to the MATLAB prompt, then it will "Use mexAtExit to register a function to call just before clearing the MEX My reason for using realloc is to offer the caller efficiency in the case "If the new size you specify is the same as the old size, realloc is I've used C/C++ memory allocation within MEX code for a long time without David On Fri, Nov 6, 2015 at 1:37 PM, Anderson Bravalheri <
|
|
I should also mention that I did not attempt to document the change to the API. The function zmq.core.recv no longer accepts the second argument as a string. This means that the shorthand syntax zmq.core.recv(socket) works the same as before, but you can't call zmq.core.recv(socket, flags). You have to call zmq.core.recv(socket, len) or zmq.core.recv(socket, len, flags). |
|
Thank you for the explanation David, it seems a good reason for me. I've fetched the pull request and played a little bit, it seems to not have a side effect in the overall architecture. I'm in favor of merging, but I prefer let Ashton take care of it, it's been a while since my last contribution... I'm not that sure about the change in the API. Despite of been more compliant with original C API, it is less expressive. But we have a higher level OO interface, so I think this change will not change the common usage... -----Original Message----- I should also mention that I did not attempt to document the change to the API. The function zmq.core.recv no longer accepts the second argument as a string. This means that the shorthand syntax zmq.core.recv(socket) works the same as before, but you can't call zmq.core.recv(socket, flags). You have to call zmq.core.recv(socket, len) or zmq.core.recv(socket, len, flags). |
|
Hi Anderson, where can I find the higher level API?
|
|
Hi David, sorry for the lack of documentation. The higher level API is composed by Context and Socket classes. This two classes are loosely inspired by the python API design. |
|
I need to have a more in depth look at this and test it to make a final decision here. Sorry for the delay. |
|
Ashton, Thanks for looking into this. I have been using the modified version for David On Wed, Feb 17, 2016 at 8:56 PM, Ashton Fagg [email protected]
|
3 participants
Fixed a performance problem when receiving large messages of unknown size. Also, changed the recv() inputs to more closely match the zmq API (without breaking any unit tests). The zmq API requires a buffer allocation for the largest anticipated message (if the buffer is too small, then the message will be truncated). The previous implementation of matlab-zmq recv() triggered allocation/deallocation of the largest anticipated buffer during each call from MATLAB, even if the actual message received was trivially small. With the submitted change, the buffer is declared as a static variable and the memory is (re)allocated using realloc. Finally, mexAtExit is used to register a function to free memory on program termination.