Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Halve the buffer counts when tracing to circular buffers
On some machines (including my awesome 24-core 48-thread Z840 workstation) tracing to circular memory buffers has, for a long time, been virtually useless. If tracing has been running for a while then saving a trace can take many minutes. It should not take longer than 30-60 seconds. The problem has been reported to Microsoft. All I know is that EtwpCopyLogHeader ends up calling ReadFile(1 MiB) hundreds of thousands of times, even though the file being read is only about 600 MiB. And I know that halving the number of buffers seems to help a lot. And I know that you can run bin\metatrace.bat to trace the trace saving process which *never* ceases to amuse me. This is what allowed me to give an awesomely detailed bug report (see the EtwpCopyLogHeader paragraph) and to find that the trace saving process was CPU bound in the kernel in memcpy. Yep, memcpy. That deserves repeating. KernelBase.dll!ReadFile is CPU bound in memcpy for ~99% of the trace saving time. How cool/horrible is that? The maximum kernel/user buffer sizes for circular-buffer memory tracing in UIforETW used to be 600/100 MiB, leading to 700 MiB trace before compression. That is actually larger than desired, in most cases, so reducing this to 300/50 MiB could be good on multiple levels, We will see. I should really add options to the settings dialog to scale the buffer sizes for different scenarios, but not today. Pull requests welcome, as always.
- Loading branch information