On Fri, 21 Mar 1997, Theodore Y. Ts'o wrote:
> Cc: submit-linux-dev-kernel@yggdrasil.com
> Date: Fri, 21 Mar 1997 12:20:15 +0800
> From: "Michael O'Reilly" <michael@metal.iinet.net.au>
>
> Ahh yes. It would be a major memory win (very few of them were using
> more than 32 fd's), but from my point of view it would complicate the
> patch, and slow it down. I belive it's more suited to be a kernel
> compile option, than a permenant place in the kernel.
>
> This is called false optimization; checking to see if there were less
> than 32 file descriptors takes exactly one comparison; at worst you
> might need another comparison at the end of select() to determine
> whether or not you need to free fd_sets. So we're talking about two
> jumps, and possibly two pipeline stalls, at worst.
>
> The code might get a little bit bigger, but select() isn't in a tight
> loop, so it's not like there are going to be any cache effects by
> spreading out the code a little.
>
> Most importantly, select() isn't critical path code!!! If the execution
> time of select gets increased by (say) 20 or 40 cycles, no one is going
> to be able to notice the difference. We're talking nanoseconds
> here.....
Quite a few nanoseconds though. Light only travels around 1.5 feet in a
nanosecond you know. :-)
Flood "Wow, my telnet connection to Mars is *really* lagged this time of
year!".
+-------------------------------------------------------------------+
+ -- Finger: flood@evcom.net for my PGP public key -- +
+-------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMzLnoBsjWkWelde9AQGqMwQAnVsqaLnuiMV58BgoXemQYjOvZyteB4IZ
cbIhXvaIQgfGzUgd78iQjJbkYDXOM13xAFeSdmQCCZY0jqYm66SP4vVvdXCGQHl+
71iKhE3SCvQsacaWNXYTTa0WwFsMKZhNFU0aT3CKlF0P+sbyhmxd/iM0Xxp3cUth
gFo1ylFi8Tc=
=o9I4
-----END PGP SIGNATURE-----