Re: BSD sockets ::select() performance on 10.4.9
Re: BSD sockets ::select() performance on 10.4.9
- Subject: Re: BSD sockets ::select() performance on 10.4.9
- From: Terry Simons <email@hidden>
- Date: Tue, 10 Apr 2007 12:22:30 -0600
Hi John,
If you always have data to read, select will return immediately and
cause your application to process the data... I don't think there is
a way to make select behave differently in this case.
Are you using exception/write fd sets, or just the read sets? In one
of my applications I initially had write sets turned on, and saw a
CPU spike, presumably because select was returning immediately due to
at least one of the descriptors being writable (which is almost
always the case).
My application doesn't have a lot of data, though, so removing the
write sets was enough to settle things down.
You could impose some sort of artificial sleep condition every now
and then to force your application to yield the CPU, but that could
cause performance issues too.
I'm definitely no expert, though, so maybe someone else has better
input.
- Terry
On Apr 10, 2007, at 11:14 AM, email@hidden wrote:
Hello, all ...
I'm working on a network application that runs on Windows as well
as Mac OSX. It's written in C++, and 99% of the code is portable
between the two operating systems. However, the OSX version
currently uses a lot more (read: 4-5x or more) CPU than the Windows
version, and i'm trying to figure out why.
So, I start the app and then run Shark, selecting "Time Profile".
What it seems to be telling me is that this app spends most of its'
time (50%) in ::select(). This makes sense, as this app
communicates over the network a lot to other nodes, though this
test is run locally e.g. it's not trying to connect to anyone else
and is just waiting for someone to connect to it. Still, it makes
me wonder how I can optimize it, while remaining cross-platform
(platform-specific code is allowed, though we try to keep it to a
minimum, as we may have to port this to Linux and possibly the PS3
soon).
However, the weird thing is that, when ::select() is using most of
the CPU, it's called from selprocess() / uiomove() / thread_block
() / thread_block_reason() / ml_set_interrupts_enabled(). I've no
idea what that stuff is, so I guess I should go looking in the
kernel. Is this the same ::select() that I use when looking for
ready sockets? Shark seems to be telling me that it is (it points
to the same address as ::select() when called from my select
loop). If so, is there a way I can optimize its' use when called
via selprocess() / uiomove() / thread_block() / thread_block_reason
() / ml_set_interrupts_enabled() so it doesn't use so much CPU?
My questions:
1. Am I interpreting the Shark output correctly?
2. If so, how can I make select() perform better in this case?
Regards,
John
Falling You - exploring the beauty of voice and sound
http://www.fallingyou.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden