Kevin B. Hendricks wrote:
> > On some OSes, poll() has
> >turned out to be a performance dog compared to select().
>
> .
> .
> .
>
> Given that select must look through all of the fds+1 that you are selecting
> over and poll does not, a true "poll" should work much much faster for
> larger sets of fds. This is the reason the kernel 2.X series is moving to
> "poll" and away from select. In fact, inside the 2.1.XXX kernel code (and
> I assume 2.2*) select is actually implemented in a poll-like manner.
At the risk of drifting a bit off-topic... both poll() and select() pay
attention only to the fds they're told to. True, select() needs to
extract that information out of bitmaps and poll() doesn't. OTOH, poll()
extracts that information out of fat data structures; if you're polling
more than a handful of fds, you're going to be passing a lot more data
between user space and kernel space. In either case, the kernel's real
work of checking the fds is more time-consuming than the minor task of
ascertaining which ones to check. And, as poll() is a much more capable
interface, the kernel has every available opportunity to be slower about
it. It's far from a given that poll() is faster than select().
> I do believe, poll is correct for the present and future of the JVN, select
> is okay for small sets of fds, but a true poll should be faster and allow
> for future expansion better.
No question poll() is a better and more expandable interface, and the
wave of the future for the JVM and everyone else. But it doesn't come
for free. I'd still like to see a comparative benchmark that flogs a few
thousand fds.
Nathan
