[mcculley]

Digging around in Instruments is the opposite of accessible.

Every OS always had easy ways to tell if a process is waiting on disk or network (e.g., top, Activity Monitor). The mechanisms for measuring how often a process is waiting on memory exist, but you have to use profilers to use them. We are overdue to have them more accessible. Think of a column after “% CPU” that shows percentage of time blocked on memory.

[saagarjha]

What would you do with that information? You'd need a profiler (and either a copy of your code, or a disassembler) to make it actionable…

[mcculley]

I would do the same thing with the information I get from top and Activity Monitor: use that to guide me to what needs investigating.

I am often developing small one-off programs to process data. I then keep some of these running in various workflows for years. Currently, I might notice a process taking an enormous amount of CPU according to top, but it might really be just waiting on memory. Surfacing that would tell me where to spend my time with a profiler.

[saagarjha]

I’m having a very hard time imagining how you would go from a “percent time waiting on memory” to something productive without doing more work in between. Even assuming you’re dealing with your own, native code, the number tells you almost nothing about where the problem is. The only process I’ve ever seen working is “hmm I have a CPU-bound performance problem (as reported by e.g. Activity Monitor)” → “I used a profiler and the problem is here or it’s spread out” → “I used a specialized tool”.

[mcculley]

> The only process I’ve ever seen working is “hmm I have a CPU-bound performance problem (as reported by e.g. Activity Monitor)

I want to be able to do the same for memory bound performance problems.

But the top level tools are stuck in the land of decades ago when CPUs were the bottleneck.

[saagarjha]

My point is that this isn't how performance work is done. You have to first diagnose that the issue is CPU-bound before it being memory bound can enter the picture. Time spent waiting for memory is accounted the same as any other CPU work, so it goes under that metric.

To make an analogy, this would be like adding a metric for function calls into Activity Monitor and using it to diagnose quadratic performance. You can't just take that number and immediately figure out the problem; you need to go look at the code and see what it's doing first and then go "oh ok this number is too high". The same applies to waiting for memory. What are you going to do with a number that says the program is spending 30% of its time stalled on loads? Is that too high? A good number? You need to analyze it in more detail elsewhere first.

[mcculley]

> Time spent waiting for memory is accounted the same as any other CPU work, so it goes under that metric.

Yes. I know. That’s my point. Tools exist to dig deeper and are not surfaced better.

I do performance work often. I simply stated that it is a shame that the highest level tools do not show us valuable information.

You are free to accept the status quo.