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
