On 06/11/2011 12:04 AM, Marko Mikulicic wrote: > Just a comment: The performance gain with epoll et al. is tied to > different API (only the file descriptors that are actually changed are > passed to and from the API). Thus implementing old-style API like > zmq_poll() on top of epoll doesn't make much sense. > > > this API issue is exacerbated by the fact that the system call crosses > the user/kernel boundary and large datastructures > have to be copied to kernel space and back again. It could be possible > to write an zmq_poll compatible implementation which detects changes in > the zmq_poll_items > arrays and applies corresponding epoll_ctl operations. The performance > improvement, if any, would depend on how this trick plays well with the > given invocation pattern of zmq_poll, > but it is at least plausible to expect performance benefits from it.
Sure. Feel free to implement it. I am a bit sceptical about possible performance gain due to two factors: 1. To find out what the differences in the pollset are, zmq_poll() implementation would have to scan and sort the pollset which has complexity of O(n log n). 2. Users of the API would be tempted to re-create the pollset before each call to zmq_poll() which would destroy any benefit which could be possibly gained by using epoll-style mechanism underneath. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
