UnixLib select and speed

Peter Naulls peter at chocky.org
Thu Dec 2 05:48:09 PST 2004

In message <BAY101-F3050F5C9333E610D9997E1F0B00 at phx.gbl> you wrote:

[ replied to GCCSDK list, as this is of general interest ]

(From Alan Buckley)

> I'm trying to port the Stratagus game engine and found that the cursor
> movement was very slow. I think I've tracked down the main culprit to a call 
> to the unixlib select statement. When this is removed the speed is much 
> increased.
> The select is used as follows:
>   maxfd = 0;
>   tv.tv_sec = tv.tv_usec = 0;
>   FD_ZERO(&rfds);
>   FD_ZERO(&wfds);
>   s = select(maxfd + 1, &rfds, &wfds, NULL, &tv);
> Is this the same as one of the speed problems you hinted at in Chox11?

Yes, it does seem that many X programs/libraries do call select() quite
a lot, and there certainly does seem to be a bit of suckiness in the

I've had a go at improving some of the cases - avoiding code when the
timeout is zero, which is quite often, and short cutting the calls to
the device specific select call.  This seems to have helped a little.

Much of the complexity arises because it needs to call the internet
module's select SWI, so it has to build up an fd_set of RISC OS socket
handles - not Unixlib's filescriptors - and then translate them back
when it gets the result.

I've considered ways of maintaining an fd_set as UL opens and closes
sockets, but I haven't been able to come up with a scheme that ends up
being useful.

> The only other thing that would make a difference in the code I'm looking at
> is if the
> select s could return a value > 0 when there was no network connection. Do 
> you
> know if this is possible?

I'm not sure if this is sensibly possible.  In any case, if there was no
network connection, you wouldn't have any network sockets open.  What
would this achieve?

Peter Naulls - peter at chocky.org        | http://www.chocky.org/
Unix Programs on RISC OS               | http://www.chocky.org/unix/

More information about the gcc mailing list