Run builds in low priority?

[Alain Dekker]

Is there any way to run builds in low priority on VS 2005 and later IDEs? In
VC++ 6 and VS 2003.NET, there was a separate process called vcspawn.exe was
launched. There was a way to hack the binary of the vcspawn.exe file so that
it was launched in low priority. This works very nicely.

With VS 2005, the IDE just runs one process called "devenv.exe" with lots of
threads. Presumably one of these threads is the compilation thread. Anyone
know of a way to hack devenv.exe so that when it launches the compilation
thread, it gets launched in low priority?

Problem I have is that VS 2005 is very slow. When you launch the build, my
project takes around 30s to build (at least) and the processor hugs 100% for
all of that time. During that time no "Windows.Invalidate" calls occur in
the IDE, causing screen whiteout for the IDE window and total
unresponsiveness from the IDE till the build has completed.

Related (and more annoying) is that because the OnUpdate handlers for the
"Cancel Build" does not getting any processing time, it neither gets a
chance to become enabled once the build has started, nor (if it could become
enabled) is it able to respond to mouse click events.

Hacking devenv.exe so that the build was only done in low priority might
help here.

Thanks,
Alain

 

[Marcel Müller]

Is there any way to run builds in low priority on VS 2005 and later IDEs? In
VC++ 6 and VS 2003.NET, there was a separate process called vcspawn.exe was
launched. There was a way to hack the binary of the vcspawn.exe file so that
it was launched in low priority. This works very nicely.

With VS 2005, the IDE just runs one process called "devenv.exe" with lots of
threads. Presumably one of these threads is the compilation thread. Anyone
know of a way to hack devenv.exe so that when it launches the compilation
thread, it gets launched in low priority?

AFAIK the compilation is done by csc.exe or something (depending on your
language) rather than devenv.exe.
I managed to run post build actions at lower priority but not the main
built itself.

In fact the most efficient way to avoid high CPU load during build is to
use a dual core CPU. VS will not use the second core significantly.

Problem I have is that VS 2005 is very slow. When you launch the build, my
project takes around 30s to build (at least) and the processor hugs 100% for
all of that time. During that time no "Windows.Invalidate" calls occur in
the IDE, causing screen whiteout for the IDE window and total
unresponsiveness from the IDE till the build has completed.

Unfortunately this is a bug in Visual Studio at least up to VS 2010.
This IDE will be frozen as long as there is *any* executable started as
child process of Visual Studio at *any* priority. This also applies if
you start a completely asynchronous process with "start /belownormal".
Any other concurrently running application is not affected.

Related (and more annoying) is that because the OnUpdate handlers for the
"Cancel Build" does not getting any processing time, it neither gets a
chance to become enabled once the build has started, nor (if it could become
enabled) is it able to respond to mouse click events.

Hacking devenv.exe so that the build was only done in low priority might
help here.

No, it won't, because it is not a priority problem (otherwise it would
not appear on multi-core systems). There is simply no thread servicing
the message queue at this time.

They must have done some dirty hack to capture the result from the
spawned build tasks. And this hack is in the GUI thread of VS and blocks
until some event happens. Most likely when any of the child process
terminates or something like that.

This becomes even more uncomfortable if you use the Sandcastle Helpfile
Builder which takes 10 minutes to complete rather than 30 seconds.


Marcel