Re: Stupid Instruments questions
Re: Stupid Instruments questions
- Subject: Re: Stupid Instruments questions
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 19 Oct 2011 00:48:08 -0400
> I was being partially facetious, but there was a genuine difficulty behind it. If you know of a better approach, I'd be more than happy to learn about.
Well, today, System Trace and/or Time Profile (All Thread States). However, the underlying parts of Time Profiler have the ability to do exactly what you want - show you samples from only threads which are blocked (or not running, or any of several other similar - but not synonymous - states). That functionality just might not be exposed in the GUI - I haven't checked recently; if not, I'd suggest filing a bug report asking for it. It would be a trivial addition.
> When I tried to profile the app in Instruments, I tried to find the threads that were busy enough to merit some optimization attention. I'm glossing over the details, but basically what Instruments told me about any given thread was that it was waiting 95% of the time, and the other 5% it was doing things with minuscule percentage contributions to the whole. There was nothing in there that pointed in the direction of any given trouble-spot.
If you're running an All Thread States profile, you'll see the callstack of the code while it's blocked. That'll typically give you a first-order hint as to why it's blocked (e.g. it might be sitting in a syncronisation primitive, or a blocking system call, etc).
System Trace will give you the same information (give or take the callstacks; again, I don't recall how much Instruments actually provides in the GUI) - though with more detail on some key aspects. For example, you can more clearly see the exact, individual system calls (including blocking syncronisations). So you can get a clearer picture of the frequency of your blocking, the mean intervals, etc. That's often crucial to understanding.
System Trace will also show you other reasons for blocking, such as being pre-empted or being stuck in VM operations (though All Thread States can also hint at the latter, if you collect kernel stacks as well). That's generally more of interest in CPU-bound, rather than IO-bound, code.
> Information about the time the thread spent waiting just wasn't helpful or relevant. I guess the point is that I didn't actually care about *time* anything took, per se, but wanted to know how many CPU calories were being burned by various methods, within the context of an individual thread. I don't know of anything in Instruments that would help, but I'd be glad to be proven wrong.
You should be able to get this info, as I allude to above. You can focus in on a specific thread, for example, after recording.
_______________________________________________
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