Take a look at these four profiles from bug 1678800, from a two-core machine:

1. Compositing in GPU process, stack sampling enabled: https://share.firefox.dev/3bOrqp9
2. Compositing in parent process, stack sampling enabled: https://share.firefox.dev/3imQogq
3. Compositing in GPU process, stack sampling disabled: https://share.firefox.dev/3bPzWnL
4. Compositing in parent process, stack sampling disabled: https://share.firefox.dev/2KwS1fi

In the "stack-sampling enabled" profiles, you can see that there are long gaps between samples in whichever process the compositing happens. Or, in other words, the profiler's sampler thread somehow only gets very few CPU resources if compositing is happening in the same process. Sampling in the other processes is fine.
Furthermore, if you compare the Styles markers on the parent process main thread in profiles 1 and 2, you can see that, if the parent process has bad sampling performance, the main thread in that process also has bad performance: There are very long Styles markers in profile 2 but not in profile 1. So, somehow, if the sampler doesn't get many CPU resources, this causes slowdown in the parent process main thread.
On the other hand, if stack sampling is disabled (and the sampler no longer interrupts the sampled threads), you can see that having compositing in the parent process does not seem to disrupt the performance of the parent process main thread; there are no long Styles markers in profile 4.

Maybe that's too much to ask for, but it would be great if our sampler didn't cause performance problems for the profiled threads. It would be nice to understand what exactly happens here (what the CPU scheduling is like, how SuspendThread affects it, etc.).