I've seen a number of profiles recently where one of the content processes looks like this: https://share.firefox.dev/313RLKH - it contains only very few samples.

Why didn't we collect more samples? Was the sampler thread starved by the CPU scheduler? Did this affect the entire process or just the sampler thread?
What CPU priority did we set on this process? For content processes that only have background tabs, we reduce the priority. Did this happen here?

I think we need to collect two types of data to answer these questions.

1. We need to capture the process priority (or maybe even the priority changes over time) in the process's meta information in the profile JSON (bug 1667818).
2. We need to find out whether the sampled threads were able to do work in those long gaps between the profiler samples, by gathering the thread's elapsed CPU time (bug 1329600).

In this other section: https://share.firefox.dev/2USQYs3 , around 41.525s we can see that Web Contents 5 and 6 take a few samples but 8 other processes above stop sampling.
It would be interesting to get more information about the CPU (number of cores&threads), but it looks like 8 CPU threads were flat out serving 8 Firefox processes, and then the OS switched to other processes for a short while...

So yes, process priority would be interesting to have, and the CPU times.
Seeing that the parent process seems most stable, it could theoretically gather CPU measurements of its child processes, so we would get more precise measurements when those child processes don't sample anything.

On Windows, there's also an API to get the idle CPU time, it would help confirm how busy the overall system is.

Other ideas?

Another example: https://share.firefox.dev/3kVHEy1