Date: Sun, 8 Jul 2007 14:58:51 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Diane Bruce <db@db.net>, freebsd-arch@freebsd.org Subject: Re: select timings Message-ID: <20070708145714.B537@10.0.0.1> In-Reply-To: <20070709021408.GK3434@turion.vk2pj.dyndns.org> References: <20070709004640.GA61639@night.db.net> <20070709021408.GK3434@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Jul 2007, Peter Jeremy wrote: > On 2007-Jul-08 20:46:40 -0400, Diane Bruce <db@db.net> wrote: >> It is a rather naive test program, close all fd's except >> for 0,1,2 of course, then open /dev/null multiple times, then do >> a select() on each descriptor. ~db/selt.c > > Thanks for the testing. Can you please feed the output through (eg) > src/tools/tools/ministat. > >> I will be trying some other select tests. >> I suspect with a sparse fd_set, jeffr's results will be better than stock. >> We'll see. > > Having a very large number of selected FDs return ready is unrealistic > - I can't think of any real-world situation where this would occur. A > more realistic situation would look like a Poisson distribution with a > small lambda (probably 1). Writing a test suite for this is probably > significantly more effort than your selt.c Well this test is useful because it shows the expected worst case for this patch which is very encouraging since one version of it is not slower than the original select code. That means in the best case we would expect my patch to be much faster. For example, if there were 8k fds and only one triggered my patch only calls fo_poll() on one fd and simply frees the other descriptors. Contrasted with the original code which calls poll all over again on each. Thanks very much for your help Diane. Jeff > > -- > Peter Jeremy >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070708145714.B537>