Re: CPU sampling and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
Re: CPU sampling and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
- Subject: Re: CPU sampling and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
- From: Paulo Andrade <email@hidden>
- Date: Sun, 15 Nov 2009 17:11:29 +0000
Thank you both. I have finally understood what's going on :).
On Nov 15, 2009, at 7:19 AM, Joar Wingfors wrote:
>
> On 14 nov 2009, at 03.20, Michael Ash wrote:
>
>> On Fri, Nov 13, 2009 at 1:28 PM, Paulo Andrade <email@hidden> 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@hidden)
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:
This email sent to email@hidden