07-31-2017 06:02 PM
I'm interested to know if there is any overhead associated with VIs that are listed (or VIs that match the pattern) in server.vi.access in the INI file.
My original plan was to explicitly list all of the VIs to which I need access however, I've come across a situation where I need to interact with clones whose names I do not know prior to run-time. So, the easiest solution for me is to use server.vi.access = "*.*" but was wanting to know if this will add any unnecessary overhead.
I'm hoping that the access parameter is only used to verify permissions to access that VI and doesn't add any overhead to the application.
08-01-2017 03:53 PM
Hi NathanJD,
Could you provide more detail of what you are trying to accomplish? If you could replicate your code without using server.vi.access, you could monitor the CPU Usage for both cases, and compare.
08-01-2017 04:45 PM - edited 08-01-2017 04:47 PM
I'm currently dynamically setting server.vi.access in the INI file prior to launching one of several applications (to be accessed via VI Server). However, I'm running into an issue where it is becoming cumbersome coming up with this list dynamically. So, opening access to everything (server.vi.access = "*.*") would actually be the easiest (because I wouldn't need to create the list) but want to know if opening all VIs to access, adds any overhead.
I could try to do some empirical benchmarking but I figured this would be an integral part of VI Server and should be well known.
08-02-2017 03:22 AM - edited 08-02-2017 03:26 AM
I don't think it makes a noticable difference in performance. These patterns are checked whenever a remote client tries to open a VI reference so the only operations that will be slowed down is the actual pattern matching in VI server when such a request arrives. A match anything pattern is actually likely to require less computing power at that point than a more or less long list of VI names or patterns. But unless you are going to open these VIs in a fast loop over and over again remotely, such performance optimizations fall not even in the category of premature optimizations but are simply spilled time on your part!
However I would be more concerned about security here. It opens the LabVIEW application to execute anything remotely that your application contains.