IDE is starting compiler at normal priority

Question

The IDE is starting the compiler at normal priority. This in effect monopolizes the computer, if the number of compile jobs are identical to the number of CPUs. Do the Visual Studio developers still not know, that a multitasking OS does not magically increase the numbers of CPU by software?

Answer 1

Normal priority doesn't make it monopolise the system at all, since that is the default priority that all processes get. Also, if you did get cl.exe to run at below normal and there were no other processes scheduled for execution, it would still get all of the processor time. All the priority does is says is in what order threads get the processor. If there are multiple threads with the same priority then it will get shared evenly between them, and this is the basics of a multitasking operating system.

I often build stuff on my home system, and I don't have any problems with performace of my system during builds. I've had all cores used up with building and a video playing at the same time, and the video was playing back with no stuttering and no sound sync issues.

---

Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Visit my (not very good) blog at
http://ccprogramming.wordpress.com/

Answer 2

First off, I would guess that IDE does strictly nothing with regard to priority when starting any external tools, compiler included (meaning, if you change the process priority of your devenv.exe to e.g. real-time, then compiler, linker etc would all be ran with real-time priority; and then, they would pretty much monopolize the system). You should check that first.

Second, you seem to have a major misunderstanding on what Windows does. Your computer is running much more processes, and they launch even more threads, than there is CPUs. And yet, you don't seem to complain about that, do you? That's because windows (and others of it's kind, e.g. Linux) is a so-called preemptive multitasking OS, and these do a fair amount of work to allocate CPU time for processes (threads, rather) that do need it. To do that, they preemptively interrupt  and schedule threads. So nothing "monopolizes" the computer. What does happen, however, is that computer does get seemingly slower when busy, because more threads are allocated CPU time, giving threads that you are interested in (those who run UI stuff) less CPU time. But hey, your machine is working, what do you expect?

Now... When you build multiple projects inside one solution, Visual Studio does launch one compiler process per  CPU (if project dependencies allow that, I guess). That's fine by m;, when compiling, I rather want it to be done as quickly as possible.

Goran.

Answer 3

> Now... When you build multiple projects inside one solution,

> Visual Studio does launch one

> compiler process per CPU (if project dependencies allow that, I guess).

> That's fine by m;, when

> compiling, I rather want it to be done as quickly as possible.

 

other people may want to use their computer while a build is running.

I want NT3.51 back -- this still had some focus-controlled-multitasking!

 

BTW -- great that I have to deal with identation/quoting myself here.

Answer 4

You know you also can turn this off. It is in Tools->Options->Projects and Solutions->Build and Run. Also the window with focus does get a priority boost in Windows. I've also had some really heavy builds running on a dual core system using both cores, and the computer was still perfectly usable. But I also agree with Goran, I would rather the build be done as fast as possible.

 

---

Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Visit my (not very good) blog at
http://ccprogramming.wordpress.com/

Answer 5

Goran:

> That's fine by m;, when compiling, I rather want it to be done as quickly as possible.

Crecens2k:

> But I also agree with Goran, I would rather the build be done as fast as possible.

 

Somebody else, who does not know, what effect a CPU priority has.

I appreciate, that a build with priority idle takes longer, in case of I'm using the machine meanwhile.

(A build with priority idle takes the same time as a build with normal priority,

if nothing else is runnable on this machine).

I appreciate to have %100 CPU power available, while a build is running.

This was obvious to me, since 1996.

Maybe you appreciate to take a break, while a build is running.

 

Foreground priority boost, while advertised in many OSs, was only detectable by humans, in NT3.51.

After Nt4 came out, I reinstalled NT3.51, since I wanted to work with the machine.

Later I wrote some message-hook, which did the same.

I'm really curious, that only few people are able to identify this as an issue.

Answer 6

I am afraid I am in Cresens' camp.  Sure, the compiler may be using 100% of both cores *IF* I am doing nothing else, but the second i do something else, that something else gets at least 50% of every CPU core -- which is the point of a multitasking OS. 

Frankly there is not a whole lot that I do while compiling where I can tell the difference whether I have 50% of the CPU time or 100%.  Modern CPUs are simply fast enough for 90% of what we do, even if we only get 50% of that CPU power.

Now sure, if I am doing something else CPU intense like transcoding video, I might notice.  But frankly I would put my video transcode at a low priority and let the compiler dominate CPU time in that case.

Answer 7

other people may want to use their computer while a build is running.

I think that you are having some other problem. I certainly am able to e.g. browse MSDN, type some text, or whatever, while the build is running. I have 3-4 year old machine, 5GB memory and I am often running 2 or more devenv.exe instances. I have never noticed a relevant (for my measure of that word) build-induced performance drop. All that said, in my experience, link and browse database generation phases are rather hard on performance (I am guessing due to a lot of disk access).

As you say, it is highly unusual that nobody is complaining about this but you. Could it be that you system is using memory in such a manner that when build starts, it starts swapping a lot and you see a performance drop?

Can you give some ballpark figures on that? (e.g. "it takes 3 sec to start program X when build isn't running, and it takes 30 when it is?", or "I when I type in notepad while build is running, letters do not appear fluently when the build is running", things like that?).

Goran.

Answer 8

 

> that something else gets at least 50% of every CPU core -- which is the point of a multitasking OS.

 

> Modern CPUs are simply fast enough for 90% of what we do, even if we only get 50% of that CPU power.

 

Very curious

Watch that you avoid full throttle -- your car may downshift by itself!

Answer 9

> Can you give some ballpark figures on that?

> (e.g. "it takes 3 sec to start program X when build isn't running,

> and it takes 30 when it is?",

> or "I when I type in notepad while build is running,

> letters do not appear fluently when the build is running", things like that?).

 

I'm not working for Microsoft.

I'm bussy to do this for my own applications.

Answer 10

I remember some years ago somebody published a hack for some visual C++ version

-- editing the excecutable file  devenv.exe to do exactly what I want to achieve.

So I'm not the only one who is able to recognize this as a problem.

 

Answer 11

http://www.codeguru.com/Cpp/V-S/tips/article.php/c439/

Answer 12

Well, if you really want to go that route, I would suggest that it would be easier and safer to just rename cl.exe to something else (cl.real.exe) and then write your own cl.exe stub that simply relaunched cl.real.exe at whatever priority you want.

You might also want to try installing Visual Studio on a clean machine and see if you continue to notice the problem on that machine, since you do seem to be in the minority here as far as noticing that the entire machine gets sluggish.