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 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]
