Every month, I run a customized Perl script that reads in a bunch of Web server log files and tallies up Web service statistics. The script works well, with one exception: It's a processor hog. The script has to read in hundreds of megabytes of data, so it takes more than 1 hour to finish. And while I run the script, the perl.exe process consumes approximately 80 percent of my CPU processing time, making other work at the same machine agonizingly slow. I thought, "There has to be a better way to do this!" As it turns out, there is: I modified the script to run at a lower priority. Now, the OS gives other running applications more processing time than it gives the Perl script. The script takes a bit longer to run—but using the machine during that time is no longer painful.
Application Priority Classes
Today's multitasking OSs simultaneously run multiple applications by granting each process a certain amount of time to run, then cycling through the processes. The OS uses a process's priority class to determine the amount of CPU time that each processor receives. Windows 2000 and later recognizes six process priority classes:
- Idle—Processes in the Idle class (aka the Low priority class) run only when no other processes are consuming processor time. A process in this class, which grants the lowest possible priority, will surrender processing time whenever another process requires it. Screen savers run in the Idle class.
- BelowNormal—Processes in the BelowNormal class get more time than those in the Idle class but less time than those in the Normal class.
- Normal—The default class for most processes is the Normal class.
- AboveNormal—Processes in the AboveNormal class get more time than those in the Normal class but less time than processes in the High class.
- High—Processes in the High class are expected to respond very quickly, even when the system is under high load. The OS allocates considerable amounts of processor time to an application running processes in this class, even at the expense of other applications.
- Realtime—Using the Realtime class requires extreme caution because this class is designed to run only for very brief periods. The OS dedicates so much CPU time to any application running in this priority class that other processes become starved for CPU time. Therefore, components such as device drivers (e.g., mouse, keyboard, NIC) can be negatively affected. This class typically is used only by device drivers that need intensive processor time for a very short duration (e.g., when reading data coming in over a USB port).
To discover the priority class that an application or service is running under, open Task Manager and select the Processes tab, which displays a list of running processes. Right-click the process you're interested in and select Set Priority from the context menu. In the submenu that appears, you'll see a mark next to the process's current class. You can change the process's priority class by selecting a different class from the list—if you have the appropriate permissions.
A Matter of Permission
Any user can change the process priority of an application that he or she started. For example, when you open Microsoft Excel, you can change its priority class. However, you can only change the priority class of a process that you own (i.e., that's running under your user account), so you can't change the priority class of a copy of Excel that someone else started (e.g., in another terminal session, as a hot-switched logon session, by running runas.exe).
Furthermore, you might be limited regarding which priority class you can switch a process to. In particular, most users can't change a process's priority class to Realtime; only users who have the Increase Scheduling Priority user right can make this change. By default, only Administrators and Power Users have that right enabled. If you're an administrator who needs to assign this right to yourself or another user, you can use the Local Security Policy console (available under Administrative Tools) to do so. Keep in mind, however, that you should avoid assigning this class to applications because of the potential negative performance effect on other programs and services.
Adding Priority Support to Perl Scripts
Changing the priority class that an application runs under can help you manage your machine's processing resources. An even more useful tactic is to put code into a script to modify the script's priority. For example, you might want a scheduled Perl script to run every day but to run in the background so it doesn't interfere with other work on the same system.
You can easily add the code that Listing 1 shows to a Perl script to manage the priority of the process that's running the script. The nice feature about this setup is that any script that contains this code will always have the appropriate permissions to modify its own priority because the process it needs to modify—the process that's running the script—will always be running under the same user account as the script.
First, the code at callout A in Listing 1 loads the Win32::API::Prototype module. Win32 API comes standard with ActiveState's ActivePerl, but the module doesn't. To use the Perl Package Manager (PPM) to install the module, use the following command:
ppm install http://www.roth.net/
perl/packages/win32-api-
prototype.ppd
The code at callout B begins by defining the priority class that the script will use. When you run the script, you can pass in any valid priority class name that's listed in the %PRIORITIES hash, which defines the priority classes and their numeric values. (I'll explain how to pass in the priority later, when I give an example of a script that uses the code in Listing 1.) If you don't specify a priority class, the script will use the Low class. The code then defines the %PRIORITIES hash.