Bill Sommerfeld wrote: > On Mon, 2008-03-10 at 16:49 -0700, Sophie Hu wrote: >> I know port_getn is more efficient that select() because when some >> event happens on the port, port_getn simply return it; while by using >> select(), when some event happens, select() tries to get the socket of >> this event, and then tries to find which bit is related to the socket, >> then mask that bit, and then return, is it correct? Can anybody >> explain more? > > If you're waiting for any of N events to happen, your application has to > check up to N bits on every return from select(). And the kernel has to > look at all nfds bits in each fd_set. > > That's not a big deal if you're waiting for any of a dozen events to > happen. It's really painful if you're waiting for any of 1000 or 10000 > events, or even if you're waiting for one or two of a sparse set of > descriptors.. > > In other words, with select(), the system has to do O(N) work for each > event, where "N" is based on the largest file descriptor number in use. > > with poll(), the system has to do O(N) work for each event, where "N" is > based on the number of events (which may, or may not, be much smaller > than the N for select()). > > With port_*, you have to do only O(1) work for each event. > > see: http://en.wikipedia.org/wiki/Big_O_notation > > - Bill >
This is correct. Note that the coefficients differ, however; if each fd is ready all the time, select is more efficient since port_get() requires a call to port_associate() for every fd. Most large scale apps w/ thousands of fds open only has data available on a few at a time; for these conditions event ports are far more efficient. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
