Generate NGen symbols in parallel #1403
Conversation
|
@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:
|
No description provided.