Process Annotation

[eshrubs]

A useful feature for doing diffs between profile runs with Chrome is process annotations. Since Chrome is multiprocess comparing profile runs is tricky. If process ids are not included, then all chrome.exe processes get merged into one stack frame by pprof (since they have the same name). If the pid is included, then diffing is impossible since the stack frames have different names.

I suggest an approach for annotating process frames based on their pid.

For example a flag

--tag-pid=<pid>:<tag> would tag process with pid pid, such that the function name of the frame in pprof would be like <process-name> (<tag>).

An example with Chrome could be --tag-pid=1234:GPU, resulting in process 1234 being chrome.exe (GPU) in pprof.

Some considerations,

1. This should at least send a warning if a tag was not consumed. This means the user specified a pid that was not present in the trace.
2. This should perhaps be exclusive from the --includeProcessAndThreadIds flag, and should exit if both flags are present.

[sunnyps]

EtwToPprof makes a pseudo top stack frame that includes the thread name (or thread id if name is missing). That has the same effect as tagging stack frames. So you'll be able to identify a Chrome GPU process frames from thread names like "CrGpuMain", "VizCompositorThread", etc. at the top of the stack. This means you need to know about the thread names of course.

If we want to tag frames as suggested here, there are two improvements to the idea that I can think of: 1) UIforETW produces a .txt file identifying Chrome processes (and types) alongside the ETW trace if you select the "Chrome developer" option. We could parse that file if it's present. 2) Or we could duplicate the logic for parsing Chrome processes in UIforETW (it's a standalone binary I believe) and just do that automatically.

[henrikand]

I also feel it would be useful with the extra flags eshrubs mentions since the output from UIforETW can look like below and and it does not give us the possibility to tag all renderer processes uniquely. Same for GPU in this case.

Also, the VideoCapture process can look like this and it is not possible to know that these threads belong to the VC process without some sort of appended tag.

         5572 -   9122 context switches,  1444.63 ms CPU
    crashpad    : 
        11936 -      3 context switches,     0.24 ms CPU
    extension   : 
        13136 -    705 context switches,   125.54 ms CPU
    gpu-process : total -  27403 context switches,  4655.93 ms CPU
         8328 -  27196 context switches,  4561.26 ms CPU
        10628 -    207 context switches,    94.68 ms CPU
    renderer    : total - 137053 context switches, 25716.85 ms CPU
         3084 -     13 context switches,     0.67 ms CPU
         8332 - 137040 context switches, 25716.18 ms CPU
    utility     : total -  23239 context switches,  2569.14 ms CPU
         9168 -  16588 context switches,  1469.12 ms CPU (AudioService)
        12620 -   6651 context switches,  1100.02 ms CPU (NetworkService)

[sunnyps]

I made EtwToPprof infer Chrome process type from command line flags and add that to the chrome.exe top frame by default. Also, CPU usage stats are emitted to the pprof profile as comments. Let me know if this addresses the need for annotating processes, or if you still prefer a flag for annotating processes generally.

See the latest release notes: https://github.com/google/EtwToPprof/releases/tag/v0.3