msbuild
msbuild copied to clipboard
dotnet
Consider reducing ETW events
During investigation of graph build I have find out that we might be tracing too many ETW events.
I believe that amount of ETW tracing shall be reasonable as extensive ETW logging can cause:
- too big overhead of capturing ETW events, which could skew perf traces
- too big trace files slowing down investigation
- way too big trace files causing perfview capture circular buffer overrun which results in missing events - prohibiting some trace analysis
- all above will result into more difficult/impossible trace capturing of tools integrated with MSBuild - such as Visual Studio
Event Statistics
| Name | Count | Average Data Size | Stack Count |
|---|---|---|---|
| Microsoft-Windows-Kernel-File/Create | 4,292,940 | 273 | 4,292,940 |
| Microsoft-Build/ApplyLazyItemOperations/Stop | 3,170,927 | 32 | 0 |
| Microsoft-Build/ApplyLazyItemOperations/Start | 3,170,924 | 32 | 0 |
| Windows Kernel/StackWalk/StackKeyKernel | 2,466,245 | 24 | 0 |
| Windows Kernel/StackWalk/StackKeyUser | 1,841,718 | 24 | 0 |
| Windows Kernel/TcpIp/TCPCopy | 1,809,001 | 28 | 0 |
| Windows Kernel/PerfInfo/Sample | 1,383,667 | 16 | 1,365,310 |
| Windows Kernel/StackWalk/KeyDelete | 1,345,336 | 299 | 0 |
| Microsoft-Windows-DotNETRuntime/ClrStack/Walk | 1,090,282 | 446 | 0 |
| Windows Kernel/DiskIO/ReadInit | 784,799 | 12 | 784,799 |
| Windows Kernel/DiskIO/Read | 784,799 | 52 | 0 |
| Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Wait | 776,601 | 10 | 0 |
| Windows Kernel/TcpIp/Recv | 776,115 | 28 | 1 |
| Windows Kernel/DiskIO/WriteInit | 689,648 | 12 | 689,648 |
| Windows Kernel/DiskIO/Write | 689,647 | 52 | 0 |
| Microsoft-Windows-DotNETRuntime/GC/AllocationTick | 644,655 | 168 | 644,639 |
| Microsoft-Build/EvaluateCondition/Stop | 608,035 | 132 | 0 |
| Microsoft-Build/EvaluateCondition/Start | 608,034 | 128 | 0 |
| System.Diagnostics.Eventing.FrameworkEventSource/ThreadPoolEnqueueWork | 481,685 | 8 | 481,685 |
Based on above we shall reconsider if we need ApplyLazyItemOperations(Start|Stop) and EvaluateCondition(Start|Stop).
Easiest solution would be to have them #IF DEBUG.
Note: In case it is needed to capture at customer equivalent data are captured by Evaluation Profiling
Could also define a keyword for less voluminous events so that they can be enabled while keeping ApplyLazyItemOperations and EvaluateCondition disabled.
