I find the timeline view in the Performance Analyzer incredibly useful, but I've often been puzzled by what causes the gaps - like those in the example below:
One of my colleagues pointed out that it is possible to figure out what is causing the gaps. The call stack is indicated by the event after the gap. This makes sense. The Performance Analyzer works by sending a profiling signal to the thread multiple times a second. If the thread is not scheduled on the CPU then it doesn't get a signal. The first thing that the thread does when it is put back onto the CPU is to respond to those signals that it missed. Here's some example code so that you can try it out.
#include <stdio.h> void write_file() { char block[8192]; FILE * file = fopen("./text.txt", "w"); for (int i=0;i<1024; i++) { fwrite(block, sizeof(block), 1, file); } fclose(file); } void read_file() { char block[8192]; FILE * file = fopen("./text.txt", "rw"); for (int i=0;i<1024; i++) { fread(block,sizeof(block),1,file); fseek(file,-sizeof(block),SEEK_CUR); fwrite(block, sizeof(block), 1, file); } fclose(file); } int main() { for (int i=0; i<100; i++) { write_file(); read_file(); } }
This is the code that generated the timeline shown above, so you know that the profile will have some gaps in it. If we select the event after the gap we determine that the gaps are caused by the application either opening or closing the file.
But that is not all that is going on, if we look at the information shown in the Timeline details panel for the Duration of the event we can see that it spent 210ms in the "Other Wait" micro state. So we've now got a pretty clear idea of where the time is coming from.
No comments:
Post a Comment