Reduce overhead of Chrome's ETW tracing to make it more usable.
When Chrome's ETW tracing is enabled it can consume more than half of the total CPU time in the process, which means it is distorting the results it is trying to measure. It also puts a lot of data into the trace which cannot be viewed. The biggest consumer of CPU time, by far, is AppendAsTraceFormat, which consumes over 95% of the CPU time in TraceEventETWExport::AddEvent. Because all categories are enabled this ends up creating many large buffers. The cc::LayerTreeHostImpl events have been seen up to 22,500 bytes and cc::Picture payloads have been seen up to 3,200,000 bytes! Ironically the WPA trace viewer can't view payloads larger than 4094 bytes so all we see for this effort and overhead is "Unable to parse data". Truncating the payloads would let us see the partial data but would still leave the distortion of execution time. The long-term solution is to specify what categories are enabled in order to manage the volume of data. Until then the prudent thing to do is to disable calls to AppendAsTraceFormat. In addition, there is no reason for phase_string to be a std::string. This overhead is relatively minor but measurable. It's worth fixing because the fix is clean and simple. The net effect is to drop the CPU overhead from 33-50% down to 1-7%. This change makes Chrome's ETW tracing much more usable. R=primiano@chromium.org BUG=488257 Review URL: https://codereview.chromium.org/1140843003 Cr-Commit-Position: refs/heads/master@{#329989}
Showing
Please register or sign in to comment