microsoft
Generate NGen symbols in parallel
@sharwell, this one makes sense when you are running on a machine with few resources, but I am concerned that on production machines where the machines may be running quite hot, that this is going to have an adverse impact on the workloads on the machine. I would be OK making this an opt-in if you have cases where it makes a huge difference and you control the environment, but I don't want to make this the default.
This primarily improves the time to complete a Merge and Zip operation the first time. My concern is that we implement this change only to have it not improve the time it takes for end users to complete this operation on demand. Do you have a suggestion for how we can implement this? Perhaps an opt-out instead of an opt-in?
I hear you. The concern that I have is that there is a trade-off here. If the machine is not loaded, then this might be OK, and will complete the merge and zip faster. But if the machine is loaded, then this could impact availability, and still likely won't complete much faster. Today, most people that I talk to have an expectation that capturing a trace will have a small impact on latency, but that's about it. I realize we're not running under a job object (perhaps this is something we should consider), but I still want to make sure that we are not hogging too much in the way of resources. Do you have specific scenarios that you're trying to improve the speed on? Perhaps there is a way for us to detect this and run concurrently.
The three cases of most interest to me are:
- Merge and/or Zip from within the PerfView UI.
- Merge and/or Zip that occurs when PerfView is launched from the command line with
-mergeand/or-zip. - Merge and Zip that occurs during post processing of a recording captured by the Report a Problem tool in Visual Studio. I'm not sure this one is implemented directly by this repository, so it may or may not be covered directly by this PR.