Re: Bizarre x86 segment layout problem causing select() slowdown
Re: Bizarre x86 segment layout problem causing select() slowdown
- Subject: Re: Bizarre x86 segment layout problem causing select() slowdown
- From: Rick Altherr <email@hidden>
- Date: Sat, 3 Feb 2007 12:51:10 -0800
On Feb 3, 2007, at 12:17 AM, Dave Hayden wrote:
The Shark sample was doing the Sampler-like trace, whatever that's
called. "All Thread States"? Anyway, yeah, it says that that thread
is spending 99.8% of its time blocked on select() instead of the
typical ~96%. It's got a 90 second timeout, not very short. I don't
recall the normal time profile showing anything very interesting.
Well, if you ran "All Thread States" (TPATS for those who like
acronyms), then I would expect select() to show up. TPATS samples
_all_ threads every x milliseconds. Even if the thread is blocked,
Shark still records a sample in this mode. So, if you have a 90
second timeout set for select() and none of the fds have activity,
then TPATS will show a fair amount of time blocked in select(). THIS
IS NOT A PERFORMANCE PROBLEM. This is completely normal and expected
behavior.
If you are trying to track down a performance problem, find the
action that causes the app to respond sluggishly, take a considerable
amount of time to complete, etc. Then, collect a Time Profile of
Everything while you do that action in the app. The resulting
session will then show you what actually took CPU time to do that
action.
The only time you should use TPATS is if you are doing things like
heavy disk I/O or application launch time. In those cases, the disk
I/O will be a performance bottleneck. In those cases, TPATS will
show that your app is taking lots of wall clock time to do something
because it is blocked waiting on the disk to return with data.
Unless you are looking at app launch or your app does heavy disk I/O,
TPATS is not what you want.
--
Rick Altherr
Architecture and Performance Group
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden