Process runs slower as a scheduled task than it does interactively

I have a scheduled task which is very CPU- and IO-intensive, and takes about four hours to run (building source code, if you're curious). The task is a Powershell script which spawns various sub-processes to do its work. When I run the same process interactively from a Powershell prompt, as the same user account, it runs in about two and a half hours. The task is running on Windows Server 2008 R2.

What I want to know is why it takes so much longer to run as a scheduled task - more than an hour longer. One thing I noticed is that the task scheduler runs at Below-Normal priority, so when my task starts, it inherits the same lowered priority. However, I've updated the script to set the Powershell process priority back to Normal, and it still takes just as long.

Anybody have an idea what could be different between the two scenarios? I've ruled out differences in processor and IO load - this task is the only thing the system is used for, so there's nothing else running that could be competing for resources.

From serverfault Charlie

• Maybe scheduled tasks run at a lower priority by default.

  Use prio to force higher priority.

  Charlie : You're right that they run at lower priority, but as I mentioned, I've already accounted for that. Unless there's some priority other than process priority that I don't know about.
  From mcandre

• If you set it to run as a scheduled task as User X, and then login as User X before it's supposed to run, it should open a window in your session when it runs, it'll be running in your session.

  If you do this, does it take the longer, or shorter, period of time? I don't know what this will mean, but it may be a useful differentiator. Could there be some network access that the user account has when logged in, but not when running as a scheduled task, that needs to timeout and fail? Is the behavior different if you create a new user account and have it run as a scheduled task under that account?

  Another idea: When running it as a scheduled task - now that you've fixed the priority on your script do the sub-processes all run as Normal, or Below-Normal?

  Charlie : The subprocesses definitely run as Normal, as verified by procexp/taskman. I think the network thing isn't it, because it doesn't do any substantive network access, but I'll double-check that. The idea about running the task as interactive is interesting too, I'll give it a try.

  mfinni : The process itself doesn't have to do any network access that you know of for this to be a problem. Read this post from Sysinternals and see how something seemingly unrelated can cause hangs/slowness. http://blogs.technet.com/b/markrussinovich/archive/2005/08/28/the-case-of-the-intermittent-and-annoying-explorer-hangs.aspx
  From mfinni

• at first - you can use more than normal priority (High for example)

  at second - you have to understand, than foreground session takes some resources, mainly hard disk IO and memory so scheduled task gets less. for clear benchmark you have to logoff while you powershell script running

  and also you can try add more memory / use ramdrive / split work on several hard disk to speed up processes

  Charlie : Thanks for the ideas. The machine has plenty of memory and IO capacity, the problem is just that things run slower as scheduled tasks than they do interactively. When the scheduled task is running, there is usually no interactive logon session, so I think that's not the issue either.
  From evg345

• It appears that there is more than just "regular" process priority at work here. As I noted in the question, the task scheduler by default runs your task at lower than normal priority. This question on StackOverflow describes how to fix any task to run at Normal priority, but the fix still leaves one thing slightly different: memory priority. Memory priority was a new feature for Windows Vista, and is described in this Technet article. You can see memory priority using Process Explorer, which is a must-have tool for any administrator or programmer.

  Anyway, even with the scheduled task priority fix, the memory priority of your task is set to 4, which is one notch below the normal setting of 5. When I manually boosted the memory priority of my task up to 5, the performance was on par with running the process interactively.

  For info on boosting the priority, see my answer to a related StackOverflow question about IO priority; setting memory priority is done similarly, via NtSetInformationProcess, with PROCESS_INFORMATION_CLASS set to ProcessMemoryPriority (the value of this is 39 or 0x27). I might make a free utility that can be used to set this, if others need it and don't have access to programmer tools.

  EDIT: I've gone ahead and written a free utility for querying and setting the memory priority of a task, available here. The download contains both source code and a compiled binary.

  MadBoy : Glad you found it, thanks for sharing.
  From Charlie

• I don't have sufficient rights to comment so I'm commenting here.

  Charlie, I'd be very interested in a utility like you descibe above for setting memory priority.

  Thanks,

  Tom

  Hi Charlie,

  I looked at the utility and it seems to work great. If possible, I'd love to see one more feature added. Hey, I know beggers can't be choosers but I thought I'd ask anyway ;-)

  As I usually run batch files from the scheduler, it woyuld be great if when I didn't specify a PID, it could use the PID that it was called from. Or, some token like $$ could be used to tell the program to use the calling PID. This way, I wouldn't ever have to know the PID and, since what I'm really executing inherits the priority from the DOS shell, it would run as normal priority as well. So my syntax in the batch file could be something like

  ProcessPriority set $$ normal

  myProgramName parameters

  While it's possible to get the current PID in a batch file, it's awkward.

  Thanks,

  Tom

  Charlie : I'll look at doing this over the weekend; I'll post here when I have it done.

  Charlie : See comments on my answer above for a link to the utility I described.

  Charlie : Unfortunately it's not terribly easy to get the PID of the parent process, but you might consider switching to Powershell (instead of Batch), in which case you can get the script process ID using this expression: `[Diagnostics.Process]::GetCurrentProcess().Id`.
  From