On 14 nov 2009, at 03.20, Michael Ash wrote:
> On Fri, Nov 13, 2009 at 1:28 PM, Paulo Andrade <[email protected]> wrote:
>> Hello,
>>
>> I'm using the CPU sampler template.
>>
>> Here (http://1wzi.sl.pt) is a sample of a very simple run to prove my point.
>>
>> Here's how I collected it:
>> - Start the app and let it fully launch (it does a few request at boot)
>> - Attach instruments with the CPU Sampler template
>> - Let it run for 30 seconds and not touch the iphone
>>
>> You'll see that the time is equally divided between +[UIApplication run] and
>> +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
>>
>> Please let me know if you have any other ideas that could explain this.
>
> The CPU sampler in Instruments does not distinguish between a thread
> which is actively running (and taking up CPU time) and a thread which
> is sleeping (and taking no CPU time). This does not make it very
> useful. I recommend using Shark instead.
Michael:
Sometimes you don't care about sleeping threads, sometimes you do. And in fact,
Shark offers both modes: [1] Time Profile, and [2] Time Profile (All Thread
States). The second mode, Time Profile (All Thread States), works in the same
way as the CPU Sampler in Instruments.
If you're investigating what is clearly a CPU bound problem, then you probably
aren't as interested in sleeping threads, and in that case the Time Profile
would work well (given that it has lower overhead and provides finer
granularity). The drawback with the Time Profile is that it doesn't even show
sleeping threads in the report (only active threads show up). This can be
surprising (what, no main thread?!), and you might also miss important clues.
If you, on the other hand, are not quite sure what you're looking for yet, or
if you know that you're interested in blocking operations, then Time Profile
(All Thread States) in Shark, or the CPU Sampler in Instruments, probably would
be better.
Paulo:
You had the "Show Ojb-C Only" filter set in Instruments. While this makes the
report more compact, it also hides some important details. When I disable that,
and "Invert Call Tree" setting, I see this:
2331 Thread 0x8eff : -[NSThread main] :0
2331 _pthread_body
2331 __NSThread__main__
2331 -[NSThread main]
2331 +[NSURLConnection(NSURLConnectionReallyInternal)
_resourceLoadLoop:]
2331 CFRunLoopRunInMode
2331 CFRunLoopRunSpecific
2331 mach_msg_trap
Two things of interest to note here:
* You have the same sample count for all "frames", meaning that every sample
found the same backtrace. This is, btw., true for all threads in this report.
* The "mach_msg_trap" is symbol that you should learn to recognize as
indicating that this thread is "parked", waiting for more work. If you look at
the other treads, you'll find that they're all parked in the same, or similar,
places.
So, to summarize: Your application is completely idle in this report. You
didn't expect any activity, and there isn't any.
j o a r
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
