On Oct 18, 2011, at 19:33 , Ken Thomases wrote: Much of the time, the threads will be idle, but at least you get to see where they are waiting. When All Thread States is not enabled, it stops each CPU core every so often and, if it's running a thread from a process that's within the target scope, it records the stack trace of that thread. Therefore, it only shows you threads that were doing something. Idle threads just don't show up. I'm not sure why this doesn't fit the definition of what Quincey wants; it sounds like it to me.
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.
More than once, I've had a situation where, amongst several threads, there were various computational hotspots, for various different reasons. For example, there might be a method where a certain thread created a bitmap image rep, and the precise details of memory allocation and pixel format obviously made a difference to performance.
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.
When I looked specifically for a candidate, such as the method creating the image rep, it might say that the thread was spending 0.7% of its time there. That was higher than a lot of the other 0.02% and 0.05% etc contributions, but there was no indication of scale that called the 0.7% a problem, because everything was dwarfed into insignificance by the wait times.
Now, the reason this thread was waiting a lot was because its images needed to be passed to the main thread for display in the UI, and there was another pixel conversion (including, e.g., scaling and a colorspace conversion) that made this kind of slow.
However, the speed of the background thread did matter, and in fact if you considered what it was doing when it wasn't waiting it was spending maybe 50% of its CPU time creating the data, 25% turning it into a bitmap rep, and the rest of the time in other overheads. I couldn't do much about the 50%, but there was some hope of lowering the 25%.
In the end, I got this information by knowing in advance where the bottleneck was (the bitmap rep thing turned about to be NSData allocating memory in a way that included an entirely gratuitous memory zeroing that was incredibly slow), but I wouldn't have found that place from Instruments.
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.
[This was some time ago, so I made up all the numbers in this description, but it corresponds to reality as best I remember it.]
|