Why does niseCfg Open Configuration take 30s or more to execute?

[Teds]

I have a VI that reads the Switch Executive Configuration to programmaticly obtain the list of virtual devices on a PC.  I noticed that running the 'niseCfg Open Configuration' the FIRST time that it takes over 30s ( almost a minute it seems ) to finish executing.

What is taking so long?  Plus is there any way I can speed that up?  It is a real problem when I build this tool into an exectuable.

Thanks,

PH

[Paul-D]

Hi, this is Paul with Applications Engineering at National Instruments.

This is currently expected behavior with Switch Executive.  The NISE Open Configuration VI loads all of the information (routes, exclusions, names, etc) for each of the virtual devices on your system and the length of this load time increases with the number of devices on your system.  This is a known concern for customers, and our development team is working on a faster implementation of this VI for the next version of Switch Executive.

As for a workaround, we recommend that you only call the Open Configuration VI once in your program.  A second option that you could try is to create a separate VI to run at system startup.  It would open the NISE Configuration and store the reference output in a network shared variable to be called by your main VI.  Alternatively, if you only need the device names, you could run the Open Configuration VI once, save the names to a file, and load that file only next time the program launches.  With this, you could also have a function to Update your names, which would rerun that process at a later time, if you expect your names to change.    

Finally, I am curious how the problem gets worse once built into a executable.  Are the load times slower as an executable?  Or are you just uncomfortable deploying this and having your program sit for a period of time before functioning on someone elses machine?

Regards,

[Teds]

Paul

Thank you for the excellent response.  I will probably try your suggestion and write the virtual devices into a file and give the user an option of updating the file if desired.

I have my program set the mouse cursor to busy and I was just uncomfortable explaining why it take so long for the program to start up.  Response times were probably the same as I did not notice any difference between the development and runtime environment.

Thanks,

PH

[Paul-D]

Glad that seems like it will work for you.  As part of handling a different issue I also I did some experimentation on saving the session reference to a file, and recalling it again later, which seemed to work testing on my computer.  Below is a very basic version of it.  I didn't bother to configure the prompts or paths or anything, but it shows that the basic functionality works.