D
David Beavon 3
Guest
This is a follow-up post related to my development productivity while performing build/debug iterations in VS 2015 RC. The original post is here and lists all the different VS-related components that I find seem to consume CPU or do some kind of blocking: (VS 2015 RC and productivity during build/debug iterations)
Question:
Does anyone have any thoughts on something called "ScriptedSandbox64.exe"? If my IDE gets locked up and I kill that sucker, it can have the effect of freeing things up a bit. But then it comes back again and never solves any long-term problems.
In order to see this process in taskmgr, you just need to create a new console application and start debugging. You will see the process being launched during debugging. Killing it seems to have no adverse effects that I can tell. Ideally there would be configuration to prevent it from starting in the first place.
I'm not trying to nitpick . Instead I am seeing latencies and I am having trouble understanding where they come from or why they are involved in launching a WPF (legacy) app from the Visual Studio debugger after making a minor edit to a code file. Sometimes its fast and sometimes its slow. It is extremely inconsistent and unpredictable, even when adding a new blank line to the exact same code file and launching a build/debug session. It is a general question about Visual Studio performance and it involves the component I listed (as per a simple ProcessMonitor audit).
Thanks
David Beavon
Continue reading...
Question:
Does anyone have any thoughts on something called "ScriptedSandbox64.exe"? If my IDE gets locked up and I kill that sucker, it can have the effect of freeing things up a bit. But then it comes back again and never solves any long-term problems.
In order to see this process in taskmgr, you just need to create a new console application and start debugging. You will see the process being launched during debugging. Killing it seems to have no adverse effects that I can tell. Ideally there would be configuration to prevent it from starting in the first place.
I'm not trying to nitpick . Instead I am seeing latencies and I am having trouble understanding where they come from or why they are involved in launching a WPF (legacy) app from the Visual Studio debugger after making a minor edit to a code file. Sometimes its fast and sometimes its slow. It is extremely inconsistent and unpredictable, even when adding a new blank line to the exact same code file and launching a build/debug session. It is a general question about Visual Studio performance and it involves the component I listed (as per a simple ProcessMonitor audit).
Thanks
David Beavon
Continue reading...