How do you keep Microsoft Excel running at full speed even when it does not have the window focus?

Question

I've noticed that when Excel 2007 (and probably earlier versions) has the window focus, Excel runs at full speed which means that files open fast and long-running VBA macros execute quickly.

If the Excel window loses the focus, the thread priority of Excel seems to drop dramatically and large files that were opening when you moved the focus open sluggishly, and complex VBA macros take a long time to complete.

Is there any way to keep the Excel priority high regardless of whether it is focused or not?

I know I could boost the thread priority artificially through Task Manager but I'm not sure what knock-on effects this might have for my spreadsheets, or OS.

My system is a fast Dual Core with 4Gb RAM and is running Vista 64.

EDIT FOR CLARIFICATION:

My problem is not simply about raising the priority of the Excel process through Task Manager because this only affects Excel when it has the window focus.

The point is what happens when Excel loses the window focus.

From using Excel extensively, it appears that, by design, it deliberately lowers its own process priority when the Excel window does not have focus.

Setting a higher priority for the Excel process does not stop this from happening - it only gives Excel a higher process priority when it has the focus but it still dips dramatically when it loses focus.

In normal Excel usage (probably 99% of everyone using it), you wouldn't notice this effect but with a massive spreadsheet (around 2000 worksheets, I think) and complex VBA Macros that take a few minutes to execute, the effect is very noticeable.

Ideally, I need it to keep the same thread priority regardless of whether the Excel window is focused.

Up to now, I have just been sitting back from the computer for a few minutes during processing so that I don't accidentally click off the Excel window when it is crunching away but I was just hoping there was a better solution...perhaps a registry hack of some kind?

EDIT:

I have only ever found one other mention of this issue on the net at this link

This is the relevant quote...

However, if I make the Excel 2000 window visible to the user and also keep the window in focus, the macros execute with their expected speed. Again, the window must have focus or the macro slows to a crawl again.

Answer 1

Windows non-server editions, by default, provide a priority boost to the foreground process. When you push Excel to the background, it loses out on the boost it previously had being in the foreground; some other program instead gains the priority boost.

You can change a setting so that programs no longer get this boost. Note: This won't affect just Excel, but any program that would have otherwise qualified for a boost.

Here's how to tweak the setting in Windows XP:

1. Right-click My Computer.
2. Choose Properties.
3. Click the Advanced tab.
4. In the Performance panel, click the Settings button.

5. Click the Advanced tab. The first panel is Processor Scheduling:

   

6. Change it from the default of "Programs" to "Background services" and it should cause Excel to behave closer to the way you want when it's in the background.

Answer 2

I don't think there is a problem with changing Excel process priority to Above Normal in your case. It should not be a problem.

Don't make it highest, where it will compete with system processes.
Don't suspend it, or you can have other things suspended on it!

---

If you use Mark Russinovich's Process Explorer
to look at the priorities of processes running on your system.
It shows the following priority values and their association.

24 Realtime
13 High         : procexp.exe itself is here, with winlogon, csrss
11              : smss is actually at 11
10 Above Normal :
 9              : lsass, services.exe are here
 8 Normal       : Most things are here
 6 Below Normal
 4 Idle

You could use process explorer and try some re-prioritization for Excel.
Move it above 8, but do not go beyond 12
Above Normal at 10 should do, I expect.

Along the same lines, if you think some process is taking up too much processor time while not in focus, you could lower its priority right up to Idle.
I usually use this technique for that.

Answer 3

There's a couple of different things to consider here: When you change the priority of a process, that base priority is inherited by all it's threads, and other processes it starts. The current priority is made up from the base priority and a number of factors which determine whether it should be boosted or not - being in the foreground does not itself necessarily boost priority, but things like coming out of a wait state or doing some IO can give a short temporary boost.

I would suggest that running your Excel process with a high priority when working on these very intensive workbooks might make sense, and I would say a second shortcut called "High priority Excel" might be a good way to do this. First make a one line batch file which runs the start command with appropriate switches, eg:

start "high priority excel" /max /high "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE"

(on a 64 bit version of Windows this would be start "high priority excel" /max /high "C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE" unless you are also running a 64 bit version of Office, which is only available for 2010 onwards start "high priority excel" /max /high "C:\Program Files\Microsoft Office\Office14\EXCEL.EXE") Note that the title for the window can be anything you like, but is not optional.

Now save this as eg HiperExcel.cmd somewhere handy - maybe the office folder, or a c:\scripts folder or somesuch, or your home folder so this can roam form machine to machine. Create a new shortcut which points to this file, make the start folder the folder where the file is kept. Choose an icon for the file - browse to the Excel.exe executable then choose something other than the usual Excel icon for clarity.

Click your new shortcut and it will invoke Excel running as a high priority process, with a base priority of 13 and when running it will probably get the maximum priority for non-real-time processes of 15. Even if something else gets a boost, it should not get higher priority. Note that the foreground process does NOT get a boost of priority just for being in the foreground (not since NT4.0). So what is going on?

Re-cap what we know so far: Processes get to take turns according to priority, but not to the absolute exclusion of lower-priority processes (well, threads really, but lets keep things to processes for ease of discussion). What happens when a process gets its "turn"? It gets to run for a unit of time called a quantum. How long is a quantum? It depends...

This is where the foreground process gets to use more of the resources - when it does get a turn, that turn can last three times longer than the turns of the background processes. So it might not get a go very often (depending on priority) but when it does, it hogs it for longer.

You can choose to use short or long quantums (default is short on workstation OS, long on servers), and to have the foreground process boosted or not (variable for w/s, fixed for servers by default), and if boosted, by how much (effectively up to 3 times). Now, the tricksy part of this is that if you choose to change the multiplier, you end up with everything having very short values for quantum, whereas if you disable foreground boosting everything gets a longer but equal amount. If you disable it of course, background windows services get the same quantum as your user applications, which might not be ideal. You need to set the value in the registry at: HKLM\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation, using a bit mask. To make things easier, the most likely values you would want are:

2 = default value, means use defaults with maximum boost. defaults on workstation O/S are short and variable. 8 = fixed, short quantum (foreground and background are equal) 40 (decimal, x28 hex) = fixed and long (this is the same as server defaults) 36 (decimal, x24 hex) = short, variable but minimal boosting for foreground process. I think this is the one which will probably give you the most benefit to reduce the amount that other apps compete, but allow Excel to get more resource when in the foreground (as long as you also raise its priority).

Try it and see, I hope this helps - your mileage may vary of course.

Aside: Lots of other applications or processes do not have the CPU as their bottleneck - your examples of Outlook synching and IE browsing probably have the network, and possibly for Outlook some disk IO as more important factors in their speed, so whether they get a foreground boost or not, the impact in visible performance is probably below what you can see by simple observation.

Answer 4

There's no problem with increasing a process's priority to "above normal" or "high", just don't set it to "realtime". Can't help you with Excel specifically sorry.

Answer 5

It is possible that the priority manipulation is being done not by Excel, but by Windows itself. Windows has a mechanism where the priority of processes with windows in the foreground is boosted; so, when Excel loses focus, its priority goes back to normal (which is slightly lower).

The only page on MSDN I could find about this with a quick search is Priority Boosts:

When a process that uses NORMAL_PRIORITY_CLASS is brought to the foreground, the scheduler boosts the priority class of the process associated with the foreground window, so that it is greater than or equal to the priority class of any background processes. The priority class returns to its original setting when the process is no longer in the foreground.

From what I have heard, there are ways to disable that priority boost.

Answer 6

Just try this, it worked for me.

Not very nice way, but it actually just doubled my calculation speed! Amazing! (but I will check the results, not sure about them...)

Your userform must be at center of the screen in 1024*768. It just send by software a right click on the userform.

Full calculation, but do not use your computer while it calculates (launch other programs, windows..).

Just try and tell me how it worked for you!

'In General
Private Declare Function SetCursorPos Lib "user32" (ByVal x As Long, ByVal Y As Long) As Long
Private Declare Sub mouse_event Lib "user32" (ByVal dwFlags As Long, ByVal dx As Long, ByVal dy As Long, ByVal cButtons As Long, ByVal dwExtraInfo As Long)
Private Const MOUSEEVENTF_LEFTDOWN = &H2
Private Const MOUSEEVENTF_RIGHTDOWN As Long = &H8
Private Const MOUSEEVENTF_RIGHTUP As Long = &H10

Private Sub Optimizer()
    'activate the window
    'AppActivate "Inbox - Microsoft Outlook"
    'move the cursor where you need it, I guessed at 200,200
    'Warning here : check the center coordinates of your userform!
    SetCursorPos 512, 374
    'send a down event
    mouse_event MOUSEEVENTF_RIGHTDOWN, 0&, 0&, 0&, 0&
    'and an up
    mouse_event MOUSEEVENTF_RIGHTUP, 0&, 0&, 0&, 0&
End Sub

'Inside your code
Call Optimiser`

Answer 7

After a long night of full speed calculation, and after check, the results this morning were... totally wrong.

So I think its just a bug, the calculations are not properly done.

Clicking on the userform in calculation just accelerate the process speed, but not fully recalculate the sheet beyond. I precise I was in Real Time with prio.

Another nice thing is to tweak the process task with prio_x64_199_2367.exe, http://softziz.com/2010/11/prio-64-bit-1-9-9/

This save your process priority defined with CTRL ALT DEL, inside task manager, for future uses.

Kind Regards,

John