Dr. Damien's Development - Call Library Function Node Calling Optimization

[DFGray]

The Call Library Function Node is used to call code in external, dynamically called libraries. Under Windows, these are typically DLLs. This is usually done to incorporate functionality already existing in another form, such as an MP3 decoding library. There are three major methods to use the Call Library Function Node.

1. Use a dynamic path input to the Call Library Function Node to set the path to the library. This is done by checking the Specify path on diagram boolean on the configuration page and wiring the library path to the new reference input to the node.
2. Use a full path in the configuration dialog. This is done if the path is known and will not change when you deploy the VI containing the node.
3. Use only the library name in the path of the configuration dialog. This works if the library is already in memory when the VI is opened or the library is in the system search path.

These options are in order, slowest to fastest. Option 1 will incur a large time hit (on the order of 20ms to 30ms) on first call of the VI (yes, each VI. It may be each node; I did not verify one way or another). If the library is not loaded, it will also suffer the load time for the library. In subsequent calls, there is a penalty for parsing the input path and ensuring it has not changed. This method of using the Call Library Function Node will strongly effect the load time of applications which use it extensively and more weakly effect the run–time performance.

Option 2 will incur the usual load time hit the first time a library is called, but subsequent calls are much faster. However, it still has a per call performance penalty when compared to option 3. On my development machine, testing a sequence of three Call Library Function Nodes to the same library, I saw the following:

• Using the dynamic path input caused a 20ms to 30ms initialization time for each VI. Subsequent calls took about 300μs.
• Using the full path, calls took about 230μs.
• Using only the library name, calls took about 180μs.

These times will vary with what code you are calling. Code being called was reentrant. Running the Call Library Function Node in the UI thread will significantly slow it down. If you code is not reentrant, you may consider using a semaphore or single–element queue to lock access to the Call Library Function Node to avoid a thread switch to the UI thread and run the Call Library Function Node in reentrant mode anyway.

Using option 3 as a developer does require some minor changes. You can ensure libraries are loaded when you execute your code by explicitly loading them using operating system calls. Attached are a pair of VIs to open and close libraries on Windows systems. These can also be run standalone to load a library so the VIs do not search for it when loaded. Alternately, you can place the libraries into your system directory (Windows\System32 on 32–bit Windows systems). They will then load automatically when you open the VI. You will need to move the libraries to the system directory on development and build machines for two reasons. First, every time you open the VI, LabVIEW will search for the VI and may or may not find it. If it does not find it, your code is broken. If it does find it, you have problem two. If you save the VI, LabVIEW will also save the full path to where it found the library in the VI. This may or may not be the path you want, and will reduce your performance of the final code.

Try it yourself and see what you get. Let us know. Attached are some timing VIs to help you benchmark your calls.

[TCPlomp]

One additional note, you can replace the extension of the Library with an asterisk (*), this enables cross-platform library use!

The NI DAQmx functions only specify DAQmx.* as the library name on the appropriate platform the correct extension is inserted (dll on windows, so on Linux and mac?)

Ton

[rolfk]

---

TCPlomp wrote:

One additional note, you can replace the extension of the Library with an asterisk (*), this enables cross-platform library use!

The NI DAQmx functions only specify DAQmx.* as the library name on the appropriate platform the correct extension is inserted (dll on windows, so on Linux and mac?)

Ton

---

Mac uses framework and it is not a file but a bundle. Basically a directory with several subdirectories in there with files indicating the latest version of the shared library file to use if there are several and a few other things. Also the files in there contain Mac resource fork data so copying them to a non resource fork supporting system, renders them useless.

In traditional Apple way a somewhat overengineered system to attempt to solve a few problems all other shared library implementations suffer in one way or the other.

[Vannes]

Using Call Library  Function Node with mpusbapi.dll by microchip.

My *Vi runs more slow in win 7 64 bits Labview 2010 32 bits.

In win xp 32 bits Labview 2010 32 bits run more fast. ¿Why?

[drjdpowell]

---

@DFGray wrote:

• Using the dynamic path input caused a 20ms to 30ms initialization time for each VI. Subsequent calls took about 300μs.
• Using the full path, calls took about 230μs.
• Using only the library name, calls took about 180μs.

---

These time differences seem very large.  I'm using the dynamic path method into SQLite3.dll.  I can make 100,000 operations in about 500ms, or 5 microseconds per operation.  Each operation makes seven calls into the dll.   Thus, there can't be more than a fraction of a microsecond overhead in the dynamic path.

-- James

Note: I do pass the same path through all CLNs (and back through a shift register) and I believe this may allow the compiler to skip the rechecking of the path to see if it has changed.   

[rolfk]

---

@DFGray wrote:

Using option 3 as a developer does require some minor changes. You can ensure libraries are loaded when you execute your code by explicitly loading them using operating system calls. Attached are a pair of VIs to open and close libraries on Windows systems. These can also be run standalone to load a library so the VIs do not search for it when loaded. Alternately, you can place the libraries into your system directory (Windows\System32 on 32–bit Windows systems).

---

---

Aside of the system32 directory you can also place the DLL in the application folder (where your exe file resides) when using option 3.

[brock85]

I was wondering is there a way to call the functions in a library dynamically?

[DFGray]

I have never tried, but suspect (on Windows) you could load the library, call the function, and unload the library using Kernel32 functions (search the Windows website for function details).  I have loaded and unloaded libraries dynamically in this fashion, but never called arbitrary functions in them.  If you pull it off, let us know the details.  Check out this webpage for hints.

[Andy2015]

---

@DFGray wrote:

There are three major methods to use the Call Library Function Node.

1. Use a dynamic path input to the Call Library Function Node to set the path to the library. This is done by checking the Specify path on diagram boolean on the configuration page and wiring the library path to the new reference input to the node.
2. Use a full path in the configuration dialog. This is done if the path is known and will not change when you deploy the VI containing the node.
3. Use only the library name in the path of the configuration dialog. This works if the library is already in memory when the VI is opened or the library is in the system search path.

---

There is another method for DINAMIC using of DLL, it cobmines options from methods 1 and 3:

4. Check the Specify path on diagram boolean on the configuration page and use only the library name in the path wiring to the new reference input to the node.

In this case no errors occur when the program starts without that DLL in system.