On Dec 11, 2013, at 14:43, Pieter Hintjens <[email protected]> wrote: > On Wed, Dec 11, 2013 at 1:40 PM, Andrew Hume <[email protected]> wrote: > >> i’ve just switched to using poller and wanted to verify my “pattern”. >> i have 4 incoming sockets. 3 are (very) low volume but need low latency >> the other socket is high volume where (almost) any latency will do. >> >> my pattern is to initialize the poller with the high volume socket last, >> but when i get a hit on that socket, i read up to 100 messages before >> going back to polling. >> >> is there a better way to do this? > > Sounds right. The order that you register sockets won't be significant > IMO (worth measuring). On all systems (but OS/X specifically), you > will win by doing non-blocking reads until there are no messages left, > and only then switch to polling.
I need to get some time to test this further and prepare a pull request for the main code, but in the meantime for Andrew here’s an example of the pattern I’ve used for the half-poll that turns linux almost twice as fast and mac almost at pair with linux. https://github.com/davipt/libzmq/blob/fix-002-proxy_lat_thr/perf/proxy.cpp#L128 (note: should change those &= into NORs, but in java I think it’s ~= but it didn’t work on c) Like Pieter said, the cost of a recv(DONTWAIT) is practically zero, so it’s cheaper to recv from all sockets even if only some have data, and then revert back to poll when there’s a bigger period where no socket has data.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
