Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have got 2 applications that are both using a lot of system resources. When I decrease the priority of one in Task Manager, while increasing the other, I don't notice any significant improvement in speed in the application with the higher priority.

Why is this? Is there more going on or is there more that needs to be done?

share|improve this question
It's like real life. If you have a higher priority for getting on an airplane than another passenger that doesn't mean the flight will take less time for you! –  Mehrdad May 13 at 3:24

5 Answers 5

up vote 29 down vote accepted

Priority does not help when the bottleneck is the CPU itself. What priority actually does is affect the scheduling algorithm the Operating System uses to determine which process runs next since there are not enough processors in most systems to run every process continuously.

A higher-priority task will make its way to the top of the queue quicker, so this helps with general latency, but if your process is exhausting the entire timeslice it is allocated on actual computation then scheduling is not going to change anything there. Changing the priority is more useful when you have a process that is waiting on I/O and you want it to be more responsive.

share|improve this answer
Priority does help when the bottleneck is too many threads that are runnable. Higher-priority threads on Windows that remain runnable at the end of their timeslice will get another chance to run in preference to a lower-priority thread (Windows tries not to starve low-priority threads and occasionally boosts them). Priority has little effect on threads waiting for I/O - Windows temporarily boosts the priority of a thread after an I/O completes, depending on the type of I/O that it was waiting on. –  Mike Dimmick May 13 at 10:05

Priority is CPU time. Are all cores being 100% utilized all the time? If not, then priority would have no effect. Quite often the CPU is not the bottleneck, and it's memory, disk, or GPU resources.

share|improve this answer

Priority only matters when there are more runnable threads than available CPU cores. When that happens, priority controls which threads get to run. In most systems, there is not enough computation happening for any contention on the CPU: the threads are all blocked, waiting for something to happen. That might be waiting for you to type something, move the mouse, touch the screen, or for data to arrive from the disk, the network, some other device you've plugged in, or for another thread to finish working on a critical data structure. It might be waiting on part of the program to be read from the disk or some memory that was swapped out to be read back, rather than explicitly reading a file.

In Windows, the scheduler keeps a queue of runnable threads at each priority level. When it makes a scheduling decision - either that a thread has exhausted its quantum (permitted time before something else needs to run), meaning another thread should get a turn, or the thread has blocked and is no longer runnable, or a higher-priority thread has become unblocked - the next thread in the queue at the top priority level with any runnable threads will be scheduled. If the thread that was running has used up its quantum, it is put on the end of the queue. If it's the only thread at its priority level that is runnable, and there are no other higher-priority runnable, but not running, threads, it will get another turn.

In multicore/multiprocessor systems, there may be restrictions on which cores a thread can run on. Also, the system tries to keep threads on their ideal core and within their NUMA node so that the thread's data is likely to still be in that core's cache and it has fast access to data it created. Threads will still be run on non-ideal cores if there's no choice of what to run next.

The system makes use of various dynamic priority boosts and dynamic quantum sizes so that the foreground application gets more time (if it needs it) than background processes, and so that processes can react quickly when I/O operations complete (including mouse, keyboard and touchscreen input). In addition, priority boosting is used to get around priority inversions, where a high-priority thread is waiting for a resource that a low-priority thread is currently holding. If there's a medium-priority thread also running, it will starve the low-priority thread of processor time, holding up the high-priority thread. So the low-priority thread is temporarily boosted to the higher priority so it gets time and hopefully releases the resource that the high-priority thread needs.

Before Windows Vista, the thread priority had no effect on how quickly I/O operations completed. Since Windows Vista, I/Os can also have a priority, which by default comes from the thread priority.

Summary: you largely won't see any effect of changing thread priorities unless your CPU is heavily loaded, and even then the effect will typically be minimal. If the process has to wait for I/O or it's not contending with other processes for CPU time, it is already running the fastest it can and changing priority isn't going to make it any faster.

share|improve this answer

In general, it takes extra effort to make a program use more than one CPU (by adding multi-threading). So even if the program has the highest available priority, it may only be using one core.

Other possible issues:

  • The program could be inefficient / poorly written
  • It could be slowed down due to "slow" disk access or a slow network
share|improve this answer

Even boosting the I/O priority of a I/O-bound process will not necessarily cause it to run faster. For example, if it is a consumer of data produced by a separate, possibly remote, process, and it is keeping up with the rate at which that source produces the data, then it cannot go faster or have a higher throughput.

Contrary to what is categorically stated in the first sentence of the currently-accepted answer (http://superuser.com/a/752587/322588), priority changes are most effective when the CPU is the bottleneck, as explained in Mike Dimmick's answer (http://superuser.com/a/752864/322588). Furthermore, the statement in the accepted answer's second paragraph, "if your process is exhausting the entire timeslice it is allocated on actual computation then scheduling is not going to change anything there" is completely wrong unless the process already generally has the highest priority of all runnable threads whenever it is waiting to run. This is because in all other circumstances, raising the priority is likely to get it more timeslices per wall-clock interval.

Mike Dimmick pointed out the problems with this answer a couple of days ago, and provided a much better answer, yet the first inexplicably continues to gain votes. Its author's claim that he is merely dumbing-down his answer for us dummies is not plausible, because it is not merely simple, or even simplistic, it is flat-out wrong, at least with regard to CPU-bound processes.

Disclaimer: I do not know Mr. Dimmick, though I can tell he knows what he is writing about.

share|improve this answer
Perhaps you misunderstood; the question was about processes running quicker. CPU-bound processes will exhaust their entire scheduling unit (quantum) and then go onto a queue of ready processes at the end. In a desktop operating system like Windows, that means the process has 1/quantum-Hz chances to run every second. Changing the priority (generally) does not change the length of its timeslices. It will always take the same number of scheduling quanta to complete. Crucially, this is how Windows actually measures process runtime: number of quanta scheduled. –  Andon M. Coleman May 21 at 2:52
The process may finish sooner, but it still ran for the same number of scheduling units. When an I/O-bound process puts itself on the wait list, it may get a second chance to run and preempt a running process with a lower priority before its quantum expires if its I/O operation completes. CPU-bound processes do not have this liberty, they exhaust their entire timeslice and then go into a ready queue. It is possible for them to run immediately afterwards if they have a high enough priority, but that has nothing to do with how Windows measures execution time. –  Andon M. Coleman May 21 at 2:54
Priority on a waiting I/O bound process is fundamentally different and it can have a measurable impact on reported runtime in Windows. Again, Windows measures runtime as the number of quanta that expired (even if a process spends 1 ms out of a 10 ms quantum actually running and then voluntarily waits the remaining 9 ms for I/O, the Windows kernel counts that as 10 ms worth of user-mode runtime). Preemption can help I/O bound applications take fewer quanta to finish. Other kernels (e.g. Linux) can correctly measure partial quanta in a process' runtime, but Windows cannot. –  Andon M. Coleman May 21 at 2:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.