Configuring Windows XP for optimum application performance

[Jim Kring]

Hello all and happy holidays

I know that there are several tricks and settings for Windows XP that can help applications (and specifically LabVIEW) achieve better and more deterministic performance (e.g., disabling indexing of the file system, turning off windowing/menu effects, etc.). Does anyone know of a listing or tutorial of such settings? And, if you don't know of a listing, do you have any tips/tricks/settings that you use to achieve optimal performance of your LabVIEW applications running on Windows XP?

Thanks,

-Jim

[David Wisti]

Here's one:

While the following is for Win2k, I think it still applies to XP:

Performance Considerations for LabVIEW on Windows 2000

[Tomi Maila]

Jim, do you need background application performance or front most application performance or both? Windows XP is optimized for front most application performance whereas Windows 2003 server is otpimized for background application performance.

[Jim Kring]

QUOTE(Tomi Maila @ Dec 26 2007, 12:27 PM)

Jim, do you need background application performance or front most application performance or both? Windows XP is optimized for front most application performance whereas Windows 2003 server is otpimized for background application performance.

Hi Tomi,

This application will be running as the front most application. However, I don't want its performance to degrade if it is not the front most application, for example, if some other window should pop to the front.

Thanks,

-Jim

[Tomi Maila]

QUOTE(Jim Kring @ Dec 27 2007, 12:35 AM)

This application will be running as the front most application. However, I don't want its performance to degrade if it is not the front most application, for example, if some other window should pop to the front.

Then you should set the XP process scheduling system to work the same way as in Windows 2003 server where the front most processes don't get extra "boost". The instructions how to disable the boost for front most applications can be found for example in this blog entery. The blog also instructs how to modify the time slice used for process scheduling. Surely you can also run your LabVIEW apps under Windows 2003 server as well if you don't want to use the tricks. If you don't need to do this programmatically, you can disable the front most application boost from Control Panel -> System -> Advanced -> Pefromance -> Advanced -> Processor Scheduling.

The second thing you may want to do is to set your application priority above normal. This can be done by calling the Windows API function SetPriorityClass. I don't know if LabVIEW uses this API directly as well to set the priority of different scheduling systems. You propably can call this function directly from LabVIEW by configuring call library node to use Kernel32.dll. Also take a look at these lecture notes, beginning from page 30 the Windows XP process scheduling system is covered.

I must confess I've never used these tricks, I just know they exist. So you're on your own if you try these. Please report if you had any success.

Tomi

[AdamRofer]

Easy stuff:

1) Keep code optimized, fewest amount of other apps open, etc etc

2) There's tons of LabVIEW only stuff that you guys should list here that I can't think of

3) Keep your hard drives defragged, registry cleaned, etc etc

4) Get XP SP3 when it is released (assuming it doesn't break anything, who knows yet) -- 10% on average increase in application speed from what people have been saying

Mildly advanced fare:

1) Force the application priority AboveNormal/High/RealTime using win32 dll calls (setPriorityClass) or a third-party app that can enforce application priority based on the program (like "Iarsn's TaskInfo"). This affects a single process quite a bit for performance.

2) Optimize your quantum/process background or foreground priority (e.g. big time chunk means less switching to other processes) [see the NI link/Tomi's post above] (and my details on the same thing) -- set this according to if your "target" application is in the foreground or not, and whether or not it will always be.

3) Buy a solid-state/flash hard drive (a lot faster for HDD calls and virtual memory paging)

4) Disable the Themes service (makes things ugly but faster)

Super tweaks to (dangerously) try:

1) Disable Virtual Memory only if you can handle it and know exactly what this entails and sets you at risk

2) Disable services you don't need (sound, indexing service, etc)

3) Any of these depending on your needs

Untested uber tweakage:

1) Play around with some fun win32 calls (I haven't used these):

timeBeginPeriod

LockSetForegroundWindowgetCurrentThread

multiprocessor --> set thread to specific processor(s): setAffinityThread or setThreadIdealProcessor

setThreadPriority

2) There's a way to make certain threads have realtime priority, apparently:http://kotaku.com/336552/windows-media-pla...wow-load-faster

"...this is because media player is the only app known today that uses the MMCSS stuff it elevates the priority of threads in a process registered with MMSCS to the realtime level which cannot be done by an app itself only the MMCSS (a system component) can do that magic..."

...as long as those threads are "registered with" MMCSS, whatever that might entail.

Gotta love the magic. Hope some of these (potentially dangerous) tweaks can help.

Also, there might be something helpful for LabVIEW optimization here: http://wiki.lavag.org/LabVIEW_configuration_file/Unknown

Likely not, though.

---

Adam Rofer

[hooovahh]

I don't know if this is applicable but if you control the Operating System entirely you can create a nLited XP for the OS.

http://www.nliteos.com/

Nlite is a program that assists in modifying the XP, 2000, and 2003 install CD. With nLite you can add drivers, integrate programs, and most importantly, remove components. You can get the CD down to about 250mb and still have much of the functionality.

This solution may take some time of course since you would have to extract the files from the CD, install nLite, modify the CD re-burn the CD, then install Windows. I think disabling services would probably give you the same result.

[Gary Rubin]

QUOTE(AdamRofer @ Dec 26 2007, 07:45 PM)

1) Force the application priority AboveNormal/High/RealTime using win32 dll calls (http://msdn2.microsoft.com/en-us/library/ms686219%28VS.85%29.aspx' target="_blank">setPriorityClass) or a third-party app that can enforce application priority based on the program (like "Iarsn's TaskInfo"). This affects a single process quite a bit for performance.

We've had good luck with this.

[Falevoz Y.]

CITATION(Gary Rubin @ Dec 27 2007, 09:43 PM)

1) Force the application priority AboveNormal/High/RealTime using win32 dll calls (http://msdn2.microsoft.com/en-us/library/ms686219%28VS.85%29.aspx' target="_blank">setPriorityClass) or a third-party app that can enforce application priority based on the program (like "Iarsn's TaskInfo"). This affects a single process quite a bit for performance.

We've had good luck with this.

What is the difference with the priority in the VI property?

Yann

[Gary Rubin]

QUOTE(Falevoz Y. @ Dec 28 2007, 07:56 AM)

What is the difference with the priority in the VI property?

The VI priority refers to the priority of the thread within Labview in which that VI is executed. The Windows priority refers to the priority within the Windows tasks with which Labview is executed.

One word of caution - if your CPU usage is pegged at 100% and you've set Labview to high priority, your ability to move/minimize windows can be limited.

[Falevoz Y.]

CITATION(Gary Rubin @ Dec 28 2007, 02:01 PM)

The VI priority refers to the priority of the thread within Labview in which that VI is executed. The Windows priority refers to the priority within the Windows tasks with which Labview is executed.

One word of caution - if your CPU usage is pegged at 100% and you've set Labview to high priority, your ability to move/minimize windows can be limited.

Ok, understand.

It could be great for my curent project. Would you give an example VI?

Thanks

Yann

[Gary Rubin]

QUOTE(Falevoz Y. @ Dec 28 2007, 12:29 PM)

Ok, understand.

It could be great for my curent project. Would you give an example VI?

http://lavag.org/old_files/monthly_12_2007/post-4344-1198863394.gif' target="_blank">

The library calls are to kernel32.dll. The function names are the labels of the library calls.

Labview will remain in high priority as long as it is open. I have not tried this with built executables, but presume it should work the same.

Microsoft's MSDN webpage will give you the values for normal and above-normal priority.

[Tomi Maila]

I wrote a subVI for LabVIEW 8.0 and later that should be able to set the process priority class of LabVIEW application instance under Windows 2000, XP, 2003 and Vista. Download File:post-4014-1198863975.vi

[TobyD]

QUOTE(Tomi Maila @ Dec 28 2007, 09:46 AM)

I wrote a subVI for LabVIEW 8.0 and later that should be able to set the process priority class of LabVIEW application instance under Windows 2000, XP, 2003 and Vista.

This is one to hold on to. Thanks!

[Jim Kring]

QUOTE(Tomi Maila @ Dec 28 2007, 09:46 AM)

I wrote a subVI for LabVIEW 8.0 and later that should be able to set the process priority class of LabVIEW application instance under Windows 2000, XP, 2003 and Vista. http://lavag.org/old_files/post-4014-1198863975.vi'>Download File:post-4014-1198863975.vi

Thanks! That will come in handy.

[Falevoz Y.]

CITATION(Gary Rubin @ Dec 28 2007, 06:38 PM)

http://lavag.org/old_files/monthly_12_2007/post-4344-1198863394.gif' target="_blank">

The library calls are to kernel32.dll. The function names are the labels of the library calls.

Labview will remain in high priority as long as it is open. I have not tried this with built executables, but presume it should work the same.

Microsoft's MSDN webpage will give you the values for normal and above-normal priority.

Thank you very much!

Yann

[LAVA 1.0 Content]

I posted a list of things in this thread on the Dark-Side.

Ben

This list can also be found using the tag path

LabVIEW >>> LabVIEW_Performance >>> Optimize-Background-Services