Why is the Tick Count function slow when used with a .dll but fine with normal lab view code?

Question

when using the Tick Count millisecond timer with a .dll I've written in C, I'm getting some odd timing issues.
When I code the function I want (I'll explain it below in case it helps) in LV and run it as a subVI, feeding it the Tick count as an argument, the function runs quickly, but not quite as quickly as I would like. When I feed this same subVI just an integer constant rather than the Tick Count, it takes about the same amount of time, maybe a tiny bit more on average.
When I bring in my function from a .dll, however, I start to run into problems. When I feed my function an integer constant, it is much faster than my subVI written in LV. When I feel my .dll the Tick Count, however, it slows down tremendously. I'm including a table with the times below:
             |  Clock   |   Constant   |
SubVi:   | 450ms  |  465ms       |
.dll         | 4900ms|  75ms         |
This is running the function 100,000 times. The function basically shifts the contents of a 2-dimensional array one place. For this function, it probably won't be a huge deal for me, but I plan on moving some of my other code out of LV and into C to speed it up, so I'd really like to figure this out.
Thanks,
Aaron

Answer 1

Hi Aaron,
Thanks for posting the code -- that made things a lot clearer for me. I believe I know what's going on here, and the good news is that it's easy to correct! (You shouldn't apologize for this though, as even an experienced LabVIEW programmer could run into a similar situation.) Let me explain...
When you set your Call Library Function Node to run in the UI Thread you're telling LabVIEW that your DLL is not Thread-safe -- this means that under no circumstances should the DLL be called from more than one place at a time. Since LabVIEW itself is inherently multithreaded the way to work with a "thread-unsafe" DLL is to run it in a dedicated thread -- in this case, the UI thread. This safety comes at a price, however, as your program will have to constantly thread-swap to call the DLL and then execute block diagram code. This thread-swapping can come with a performance hit, which is what you're seeing in your application.
The reason your "MSTick fine behavior.vi" works is that it isn't swapping threads with each iteration of the for loop -- same with the "MSTick bad behavior.vi" without the Tick Count function. When you introduce the Tick Count Function in the for loop, LabVIEW now has to swap threads every single iteration -- this is where your performance issues originate. In fact, you could reproduce the same behavior with any function (not just TIck Count) or any DLL. You could even make your "MSTick fine behavior.vi" misbehave by placing a control property node in the for loop. (Property nodes are also executed in the UI thread).
So what's the solution? If your DLL is thread-safe, configure the call library function node to be "reentrant." You should see a pretty drastic reduction in the amount of time it takes your code to execute. In general, you can tell if your DLL is thread-safe when:
The code is thread safe when it does not store any global data, such as global variables, files on disk, and so on.
The code is thread safe when it does not access any hardware. In other words, the code does not contain register-level programming.
The code is thread safe when it does not make any calls to any functions, shared libraries, or drivers that are not thread safe.
The code is thread safe when it uses semaphores or mutexes to protect access to global resources.
The code is thread safe when it is called by only one non-reentrant VI.
There are also a few documents on the website that you may want to take a look at, if you want some more details on this:
Configuring the Call Library Function Node
An Overview of Accessing DLLs or Shared Libraries from LabVIEW
VI Execution Speed
I hope this helps clear-up some confusion -- best of luck with your application!
Charlie S.
Visit ni.com/gettingstarted for step-by-step help in setting up your system