I suggest you send the patch to libzmq master, and ensure all test cases pass. Then we can get this into the next version.
On Fri, Nov 21, 2014 at 2:50 PM, Francis Le Bourse <[email protected]> wrote: > Hi, > > On 11/6/2014 3:18 PM, Pieter Hintjens wrote: >> >> Oh, ok. Sounds like you have a good candidate for some before/after >> measurement and optimization. Are you going to try to make a patch for >> this? > > I have a patch candidate for this optimization, the performance improvement > is very good and it doesn't seem to introduce any new instability. > What is modified: > - zmq_poll(), there is only one poll() now, > - and epoll() from epoll.cpp > Other calls to poll() and select() are left unmodified. > > I woulld be happy to have any feedback. > > > Cheers, > Francis >> >> >> On Thu, Nov 6, 2014 at 2:09 PM, Francis Le Bourse >> <[email protected]> wrote: >>> >>> On 11/6/2014 11:47 AM, Pieter Hintjens wrote: >>>> >>>> A simple optimization is, when you are polling sockets for input, to >>>> continue reading from an active socket using a non-blocking read. So >>>> you process all waiting messages on a socket and then only switch back >>>> to poll when needed. >>> >>> Thank you for you quick reply. >>> >>> Yes, but the question was more about the zmq_poll() internals. >>> For 600+ file descriptors, zmq_poll() calls poll() a huge number of times >>> for only a few that will trigger a POLLIN and the relevant information is >>> already known / present in the pollfds array. The performance hit is >>> there. >>> >>> Cheers, >>> Francis >>> >>> >>> >>>> On Thu, Nov 6, 2014 at 11:28 AM, Francis Le Bourse >>>> <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am looking at a performance issue in zmq, when the number of zsockets >>>>> / >>>>> file descriptors becomes large. >>>>> The relevant calls are: >>>>> poll+0x57 >>>>> zmq_poll+0x2e3 >>>>> zloop_start+0x1e8 >>>>> main+0xb40 >>>>> __libc_start_main+0xfd >>>>> immediately followed by a loop of >>>>> poll+0x57 >>>>> zmq::signaler_t::wait(int)+0x33 >>>>> zmq::mailbox_t::recv(zmq::command_t*, int)+0x78 >>>>> zmq::socket_base_t::process_commands(int, bool)+0xbe >>>>> zmq::socket_base_t::getsockopt(int, void*, unsigned long*)+0x135 >>>>> zmq_getsockopt+0x75 >>>>> zmq_poll+0x3da >>>>> zloop_start+0x1e8 >>>>> main+0xb40 >>>>> __libc_start_main+0xfd >>>>> >>>>> The code in the loop is executed once per file descriptor in the >>>>> initial >>>>> pollarray, redoing a poll() system call each time. >>>>> Is there a reason to proceed that way ? >>>>> Would be possible to reuse the results of the first poll() in order to >>>>> bypass the second set of system calls ? >>>>> >>>>> Cheers, >>>>> Francis >>>>> >>>>> >>>>> _______________________________________________ >>>>> zeromq-dev mailing list >>>>> [email protected] >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>> >>> > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
