BSD sockets ::select() performance on 10.4.9
BSD sockets ::select() performance on 10.4.9
- Subject: BSD sockets ::select() performance on 10.4.9
- From: email@hidden
- Date: Tue, 10 Apr 2007 10:14:08 -0700
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