Strange Difference in Execution Times

[CaseyM]

This may fall into another sub-category, but at the moment I'm at a loss as to which one it would be. So here's the deal...

A co-worker and I have developed software for a client that takes and parses a custom script that is used to load and read settings and measurements from custom hardware.

There are two main modules in this application:

1) The script application module which actually parses the custom script and communicates with the custom hardware

2) An experiment GUI with which the user can define parameters and automatically create the custom scripts. The experiment GUI also calls the script application module to run these custom scripts.

When running a script through the experiment GUI the script application module gets called and the script takes ~2.5s to run. When running the script directly through the script applicatoin it only takes ~1-1.5s to run. What gives? LabVIEW is calling the exact same code in each case but there are wildly different execution times in running the script. It doesn't matter whether the experiment GUI calls the script application module statically or dynamically. Changing the priority of the script application module doesn't make a difference either.

This is running WinXP SP2 on an Intel Core Duo @1.83 GHz with 512MB of RAM.

Has anyone experienced something similar or does anyone have any insight as to why this difference might occur?

-Casey

[crelf]

QUOTE(cmay @ Feb 19 2008, 03:41 PM)

This may fall into another sub-category, but at the moment I'm at a loss as to which one it would be. So here's the deal...

Can you post an example of the problem? If your code's proprietary, then can you recreate the issue with a simple example?

[CaseyM]

QUOTE(crelf @ Feb 19 2008, 12:56 PM)

Can you post an example of the problem? If your code's proprietary, then can you recreate the issue with a simple example?

The code is proprietary and I don't think I can recreate the problem very easily. I know that's not very helpful, but maybe I can share some more information that might be of use.

-The experiment GUI calls the "Run Script" case in the Script Application module by enqueing that particular state.

-Script files are written to disk and are read in the "Run Script" case.

-2 commands in the script file in particular seem to carry most of the delay from the eGUI: load_configuration and write_file_to_disk

[jzoller]

QUOTE(cmay @ Feb 19 2008, 01:41 PM)

This is running WinXP SP2 on an Intel Core Duo @1.83 GHz with 512MB of RAM.

-Casey

You're running a little tight on memory. If the GUI is large, it might be causing some page file swaps that are slowing down disk access on the loads.

Just a thought. Hard to do more without concrete details.

Joe Z.

[CaseyM]

Well, after all that it turns out there was a VI running in the "background" that was hogging CPU cycles - totally our fault. Thanks for the help anyway.