Multiplexing alternatives to poll()...

[Roger Dingledine]

On Wed, Dec 18, 2002 at 09:32:03AM -0500, Bruce Montrose wrote:
> Read this article comparing the various multiplexing techniques... 
> http://www.kegel.com/dkftpbench/Poller_bench.html

I don't think we're anywhere close to bottlenecking at poll(). We have
maybe a couple dozen sockets to look at tops, at this point (but yes,
perhaps down the road when we have thousands of clients we should
reconsider).

The multiplexing that I was talking about in the previous thread happens
at a higher level than the socket level: we take all the bytes off
a single socket, and then look at them to decide which circuit (and
perhaps down the road which topic of that circuit) they're talking about.

> It would seem that either /dev/poll or kqueue could drastically improve our 
> multiplexing in the onion router.

I would be shocked to find any noticeable performance increase from
switching to these more-platform-specific mechanisms, at least with the
number of sockets we've been dealing with so far. Where we might want to
look at streamlining, however, is our prepare_for_poll() function, which
has been growing all sorts of functionality and gets run every time poll()
gets run. My plan for now is to let it keep growing that functionality,
and when it seems to have most of what we want, then I'll take another
look and see how to clean it up.

But this brings up a bigger problem -- gprof doesn't seem to work as well
as I remember from 5 years ago. So I don't have a good sense of what's
using so much time in tor. When I'm back on an actual net connection,
I'm going to look into oprofile (http://oprofile.sourceforge.net/)
and see how well that works. Other suggestions are welcome too. :)

--Roger