DLL execution time

Question

Hello,
Does anyone know how to reduce the time of calling the DLL file in the LabVIEW RT ? When I call the DLL file in a timed loops, the iteration duration shows that it needs half of a millisecond ( around 0.5 ms) to load the DLL file (inside the DLL file it do nothing just adding x to y and return the sum). Therefore I want to ask does the LabVIEW RT need to reload the DLL file every time in the timed loop?  And how could I reduce the time of calling DLL file?
PS: the DLL is made by LabWindows CVI with Real time module.
Thank you,
Yan

Answer 1

Thank you Danny, your reply is very helpful for us to understand the mechnism of how LabVEIW RT is running.
Texas_Diaz wrote:
Is it necessary to call into the DLL in the Timed Loop?  The timed loop is a...
It is very time-saving for us to use DLL file to in our project, because we are using a third party PCI card (Beckhoff FC1100 PCI EtherCAT slave card) and it's very convenient for us to manipulate the PCI card by using the C language. Therefore we want to turn this C-language-based program into a DLL and call it in the LabVIEW RT.
Okay, now that we got that out of the way, there are things you can do to optimize calls to the Call Library Function Node.
Unless your DLL entry point is deemed "non-thread-safe", and therefore must run synchronous to other calls into the same DLL entry point, NEVER use the default thread - that will use the UI thread, which controls more than just the DLL call.  Always change the thread context to "Run in any thread" so that the "current" thread (or any other ready LabVIEW execution thread) can be used.  This will significantly reduce jitter in your application and prevent certain classes of runtime deadlocks.  You can tell if the Call Library Function Node is set to UI thread or "any thread" by looking at the color of it - it will be Orange if using the "UI" thread, or Yellow if using "any" thread.
You can prevent a DLL from being loaded / unloaded each execution call by following a few simple programming techniques.  Basically by exposing the DLL path input and reusing the exact same node used to originally load the DLL, if you then call back into that very same node - but this time provide a blank path - the DLL previously loaded in memory will be used instead of reloading a/any DLL again.  This way you're dynamically loading the DLL at runtime and are allowing the node to keep the DLL in memory.
Keep the DLL call short and sweet.  
1. Yes, I enable it "Run in any thread", it can save a little execution time by 5-9 us.
2. By following the provided example, namely loading the dll file dynamically, but the execution stayed unchanged. 
3. I use a simple DLL file to do the test, so in this simple DLL file, it just execute sum = x + y, which x, y is the input argument and sum is the return value. so I think the DLL file is simple enough.
But I still have some questions:
Do you think the performance of the target machine has a profound impact on DLL execution time? Because I use 32bit desktop PC with core 2 duo CPU as the target machine.
Another question is that: 
I use the LabWindows CVI to generate the DLL file, do you think the execution time will be same if I use the visual studio to program the DLL file? Actually, I have tried use Visual Studio 2012 to generate a DLL file, but the DLL file cannot run on the LabVIEW real-time target, I think because the DLL files is generated by the Visual studio, therefore it may needs some Microsoft dependency, do you know how to generate the LabVIEW RT- compliable DLL file by using Visual Studio?