Part 1 of this article

CPU affinity

Running a process at a low priority can be taken too far in cases where processor attention is limited so much that the program gets almost no work done.

However, there is another way to free up your CPU's time. Virtually all modern PCs now come with either a dual- or quadcore CPU. These provide two or four physical processors, each of which can be running a thread at any given time. There's no special rule for sharing out these extra CPUs, though: Windows looks at quantums and priorities just as normal, and there's nothing to stop a multithreaded application tying up your processors all on its own.

You can do something about this by defining the CPU affinity for this process, as in the CPUs it will be allowed to run on. In Task Manager, click the Process tab, right-click the process, select 'Set Affinity' and clear all but one of the CPU boxes. On a dual-core processor, this means the process will now only run on one of your cores. Even if you leave it at a normal priority, the program still shouldn't grab all your CPU time, leaving you able to do other things.

It's also possible to launch a program with a given affinity setting, again thanks to the very useful 'start. exe' command, although you do have to calculate an affinity mask first. Essentially, the first core has a value of 1, the second 2, the third (if you've a quad-core system), 4, and the fourth, 8.

Decide which cores you'd like the process to run on, then add those values together to produce the affinity mask: just core 1 and it would be 1, cores 1 and 3 would be 5, and so on. Convert values over 9 to hex, then specify them in your shortcut like this, replacing 'm' with your affinity mask: cmd.exe /c START AFFINITY m c:\path\app.exe.

This is a useful technique to apply occasionally, if there's a specific program that you don't want to grab all your CPU time, but be careful. Generally, the less leeway you give to Windows own thread scheduler, the more inefficiently your PC will run. Just like priority boosting, it's best to use CPU affinity tweaks sparingly.

System resources

Controlling how your processes access the CPU is an excellent first step in optimising a PC, but there's plenty more work to do. And learning something about the limitations of your system resources can be particularly useful, at least for 32-bit Windows users. (If you're using 64-bit Windows this next section won't apply to you, sorry.) 32-bit Windows allocates 2GB of virtual address space to each process you run.

The Windows kernel also only gets 2GB to store everything – kernel code, drivers, DLLs and all the components it needs to keep your system running – so all resources are strictly rationed. Virtual memory allocations by kernel components like DLLs are taken from something called the 'paged pool' and on a 2GB Windows XP PC, that defaults to a maximum of 360MB in size.

Drivers often require memory that is guaranteed never to be paged to disk and that's taken from the 'nonpaged pool' (which defaults to a maximum 262MB on a 2GB XP PC).

Windows XP doesn't let these pools grow to meet demand, so if a buggy driver grabs all the pool memory, odd things begin to happen: error messages, network failures, hangs and more. Windows XP users can make the situation even worse if their PCs have 4GB of RAM and they use the '/3GB' switch to try and give applications access to more memory (see http://support. microsoft.com/ kb/833721 for more information). This squeezes Windows own address space down to a mere 1GB, making resources drop still further.

The maximum non-paged pool falls from 285 to 154MB and system page table entries (a resource used to map virtual to physical memory, see www.tinyurl.com/ 6j5wmg) plummets from 106,000 to around 15,000. If you've used the '/3GB' switch and your PC is now unstable, that may be why. Remove it and see what happens.

32-bit Windows Vista improves on this situation in many ways. It can now dynamically allocate new memory if either pool needs it, so your system will keep running. Still, if you've a resource leak – a process that keeps grabbing objects and doesn't release them – then even Vista will run into problems eventually. That's why everyone can benefit from monitoring their PC's resource use.

Task Manager

The simplest way to check your current Windows resources is through Task Manager. Press [CTRL]+[Shift]+[ESC] to launch it, select the Processes tab, click 'View | Columns' and ensure the 'Memory – Paged Pool', 'Memory – Non-paged Pool', 'Handles', 'USER Objects' and 'GDI Objects' are checked. Reboot your PC and make a note of the highest value in each case, as well as the paged and non-paged totals displayed on the Performance tab.

An hour or two later, take a look at Task Manager again. Anything using several thousands of handles, GDI or USER objects should be looked at closely, and Windows XP users should be concerned if non-paged pool use is over 200MB or paged pool allocations have passed 250MB. This may not mean buggy software – your application may simply be doing a lot of work – but this can help point you in the right direction. Google the process name to find out more.

The Windows Performance Monitor can also help display this data, along with some other figures that Task Manager doesn't provide. Launch 'perfmon.exe', click the plus sign to graph a new value, then open the Memory counters and choose 'Free System Page Table Entries'. If this is very low, perhaps a 1,000 or less, then you may also have a resource leak somewhere.

So where is it? If you're regularly getting complete PC crashes – the 'blue screen of death' that kills Windows and forcibly reboots your system – then there's one suite that can probably help you find out: the Windows Debugging Tools. Sure, they're aimed at developers, and they're complicated and packed with jargon, but they can also take a crash dump file and let you know whether resource problems were the cause. If they're not, then you can get some very helpful clues about the real culprit. And, despite their technical reputation, using the Debugging Tools at this level is very, very easy.

Part 3 of this article